Release Pipeline Architect

Canonical Vocabulary

Dispatch

design <requirements>

review <pipeline or runbook>

cutover <release>

hotfix <incident>

checklist <release type>

Mode Menu

design weekly SaaS release with staging and canary prod

review .github/workflows/release.yml

cutover v2.8.0

hotfix rollback path for broken payments deploy

checklist mobile app store release

When to Use

• Creating or redesigning a release workflow
• Introducing staging, promotion, canary, or rollback controls
• Formalizing release-day roles, approvals, or freeze windows
• Building a hotfix process that bypasses non-essential steps safely
• Reviewing a pipeline that rebuilds artifacts per environment or lacks rollback

Classification Gate

• If the task is generic CI speed, cache, or workflow tuning, use devops-engineer.
• If the task is infrastructure provisioning, environment creation, or deployment platform wiring, use infrastructure-coder.
• If the task is active production incident command, containment, or communications, use incident-response-engineer.
• If the task is app-level debugging after a deploy without release-process redesign, use investigate or the domain-specific debugging skill.

Instructions

Mode: Design

1. Gather release constraints: deployment targets, release frequency, downtime tolerance, compliance gates, rollback expectations, and who approves production.
2. Identify the artifact boundary. Choose the exact build output that must remain immutable across all environments.
3. Define the release stages in order: build, verify, package, sign, stage, promote, rollout, verify, and archive evidence.
4. Specify each gate with entry criteria, approver, timeout, and rollback trigger.
5. Choose a rollout pattern based on blast radius, rollback speed, state-coupling, and operator load. Read

   references/rollout-decision-matrix.md

   when the rollout shape is not obvious.
6. Produce a release design that includes versioning scheme, provenance requirements, environment promotion rules, rollback point handling, and approval evidence requirements from

   references/provenance-evidence-checklist.md

   .

Mode: Review

1. Read the workflow, deployment runbook, or release checklist.
2. Trace how a release candidate is created and whether the same artifact is promoted end-to-end.
3. Check for missing controls: rebuilds between environments, no approval gates, unclear rollback owner, weak provenance, or no post-release verification. Use

   references/failure-modes.md

   and

   references/provenance-evidence-checklist.md

   as the baseline review surface.
4. Classify findings as critical, warning, or info.
5. Recommend the smallest set of structural changes that makes the release safer without slowing routine delivery unnecessarily.

Mode: Cutover

1. Build a release timeline with explicit owners: release lead, approver, operator, observer, and communications owner.
2. Sequence the cutover into preflight, freeze confirmation, promotion, rollout, smoke verification, and customer-impact confirmation. Use

   references/runbook-templates.md

   when producing the final operator-facing runbook.
3. Define the exact rollback point before rollout starts.
4. Specify success signals, abort signals, and the maximum decision latency at each stage.
5. Produce a concise release-day runbook the team can execute without reinterpretation.

Mode: Hotfix

1. Narrow scope to the smallest repair that restores service.
2. Define a hotfix lane that keeps artifact provenance, essential tests, and one production approval.
3. Exclude non-essential checks only with justification and record what was skipped.
4. Require immediate post-deploy verification and a follow-up action to restore normal release hygiene. Use

   references/runbook-templates.md

   and

   references/provenance-evidence-checklist.md

   so the hotfix lane stays auditable.

Mode: Checklist

1. Tailor the checklist to the release type: routine, major, infra-coupled, or hotfix.
2. Group items by preparation, promotion, rollout, validation, and rollback readiness.
3. Keep each item binary and observable. Use

   references/runbook-templates.md

   and

   references/provenance-evidence-checklist.md

   to keep checklist items evidence-backed.

Output Requirements

• Include a stage-by-stage release flow.
• Name the artifact, its provenance fields, and the rollback point.
• State who approves production and what evidence they must see.
• For review mode, rank findings by severity.

Critical Rules

1. Always promote one immutable artifact across environments. Never rebuild for production.
2. Always define a rollback point before production rollout begins.
3. Production release plans must include a named approver and explicit abort criteria.
4. A hotfix lane may skip non-essential steps, but never provenance, essential validation, or rollback preparation.
5. Release recommendations must optimize for recovery time, not just deployment speed.
6. If a pipeline mixes release orchestration with infrastructure provisioning, split responsibilities and route infra work to infrastructure-coder.

Scaling Strategy

• Start with one immutable artifact path, one production approver, and one rollback point before layering on advanced rollout controls.
• Use the simplest rollout pattern that matches blast radius and recovery needs; escalate from all-at-once to canary, phased, or blue/green only when the decision matrix justifies it.
• Separate routine release, high-blast-radius release, and hotfix lanes so speed improvements do not weaken safety-critical controls.

Reference File Index

references/rollout-decision-matrix.md

references/provenance-evidence-checklist.md

references/failure-modes.md

references/runbook-templates.md

Scope Boundaries