Release and Change Gating Toolchain Planner

The Prompt

You are an operations reliability architect. Design a release and change-gating workflow using approved connectors and governed writebacks.

PREFERRED LLM / FAMILY:
{{preferred_llm}}

INITIATIVE CONTEXT:
{{initiative_context}}

CHANGE SCOPE:
{{change_scope}}

EVIDENCE CHANNELS:
{{evidence_channels}}

RISK TOLERANCE:
{{risk_tolerance}}

APPROVAL MATRIX:
{{approval_matrix}}

ROLLBACK PLAN:
{{rollback_plan}}

Return exactly these sections:

1) Release Readiness Scorecard
- Scope mapping: products, environments, and stakeholder impact.
- Decision criteria for each environment gate.
- Missing dependencies and evidence gaps.

2) Toolchain Layout
- Intake, validation, draft update, approval, and writeback layers.
- Which systems are read-only vs write-capable and why.
- Ownership and handoff paths for each connector.

3) Change Gating Rules
- Gate criteria by risk class.
- Exception handling and manual override requirements.
- Escalation thresholds and timeout defaults.

4) Execution Timeline
- Week 1 pilot, Week 2 hardening, Week 3 expansion.
- Required evidence before each gate.
- Parallelizable vs sequential tasks.

5) Draft Writeback Bundle
- Proposed draft updates for issue trackers, docs pages, and comms drafts.
- Required approver role for each draft and re-review trigger.
- Idempotency and audit details for each write candidate.

6) Control and Exit Criteria
- Keep, pause, or rollback criteria.
- What to monitor during each phase.
- Conditions that switch the workflow from green to yellow/red.

Rules:
- Only propose governance-safe draft operations.
- Keep all recommendations executable by role, not by policy-invisible automation.
- Never instruct direct execution commands or secret handling.

When to Use

Use this when a team needs a release-safe way to coordinate cross-system changes, especially when issue tracking, documentation, and communication are currently fragmented across tools.

Variables

Variable	Description	Example
`preferred_llm`	Model family for planning and consistency checks	`gpt-5`, `claude-opus`
`initiative_context`	Program context and business objective	”Cross-service rollout for user analytics pipeline migration.”
`change_scope`	Environments, modules, and affected teams	”Prod deploy, docs, and support comms; 3 squads.”
`evidence_channels`	Systems that provide decision evidence	”Jira, Slack, Notion, Confluence, CI status.”
`risk_tolerance`	Allowed risk levels and rollback constraints	”No customer-facing rollback after 30 min without director approval.”
`approval_matrix`	Approval roles and thresholds	”SME for low risk, SRE lead for medium, CTO for high.”
`rollback_plan`	Recovery actions and ownership	”Automated rollback window, comms reversal, config reversion owner.”

Tips & Variations

Add a criticality_bands field with high/medium/low impact classes and separate playbooks.
Ask for separate day-0, day-1, and day-7 review criteria.
Include a “safety-first override” rule when monitoring confidence falls below a threshold.
Require a second model review pass for high-impact routing rules.

Example Output

Release readiness scorecard shows which gate passes or fails before promotion.
Draft writeback set maps likely ticket status updates, release notes, and comms placeholders as DRAFT.
Rollback criteria include explicit owners, signal thresholds, and verification checkpoints.

The Prompt

When to Use

Variables

Tips & Variations

Example Output

Related site references