release-pipeline-architect

release-pipeline-architect1101 wordsMITRepo-owned

Release workflow architecture for versioning, artifact promotion, rollout safety, and rollback design. Use for release pipelines. NOT for generic CI tuning or infrastructure.

Quick Start

Install:

npx skills add github:wyattowalsh/agents --skill release-pipeline-architect -y -g --agent antigravity --agent claude-code --agent codex --agent crush --agent cursor --agent gemini-cli --agent github-copilot --agent grok --agent opencode

Use: /release-pipeline-architect <mode> [target]

Research context (evidence, not authority)

Problem: Release workflow architecture for versioning, artifact promotion, rollout safety, and rollback design. Use for release pipelines. NOT for generic CI tuning or infrastructure. Stack / assumptions: on-demand references; eval fixtures Comparable alternative: A general-purpose agent instruction without a scoped skill contract

Works with Claude Code, Gemini CLI, OpenCode, and other agentskills.io-compatible agents.

Repo skill (hand-maintained)

Composed compose-custom-wave-6 from skills/release-pipeline-architect/SKILL.md with full SKILL disclosure. Do not run wagents docs generate on this file (HAND-MAINTAINED sentinel).

What It Does

Design release pipelines that move one immutable artifact through test, staging, and production with clear gates, rollout strategy, and rollback procedure.

Modes

$ARGUMENTS	Mode
design <requirements>	Design a release pipeline and operating model
review <pipeline or runbook>	Audit an existing release flow
cutover <release>	Plan the release-day sequence and handoffs
hotfix <incident>	Design an emergency release lane
checklist <release type>	Produce a release readiness checklist
Natural language about release workflows	Auto-detect the closest mode
Empty	Show the mode menu with examples

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.

Canonical Vocabulary

Term	Definition
release candidate	A versioned build proposed for promotion
artifact	The immutable build output promoted across environments
promotion	Moving the same artifact to the next environment
gate	A manual or automated approval checkpoint
provenance	Evidence tying an artifact to source commit, build, and checks
rollout	The production exposure strategy: all-at-once, canary, or phased
rollback point	The last known-good release that can be restored safely
freeze window	A period where changes are limited to release-critical work
hotfix lane	A minimal path for urgent production repairs

Mode Menu

#	Mode	Example
1	Design	design weekly SaaS release with staging and canary prod
2	Review	review .github/workflows/release.yml
3	Cutover	cutover v2.8.0
4	Hotfix	hotfix rollback path for broken payments deploy
5	Checklist	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.

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.

Scope Boundaries

IS for: release trains, approvals, environment promotion, rollout strategy, rollback design, cutover sequencing.

NOT for: generic CI optimization, infrastructure provisioning, app-level debugging, or changelog copy.

Public Metadata

Field	Value
Source Type	repo-owned
Display Source	github:wyattowalsh/agents
Source Kind	repo
Installability	portable command
Review State	reviewed
Target Agents	antigravity, claude-code, codex, crush, cursor, gemini-cli, github-copilot, grok, opencode

General

Field	Value
Name	release-pipeline-architect
License	MIT
Version	1.0.0
Author	wyattowalsh

Claude Code

Field	Value
Argument Hint	[mode] [target]

Related Skills

devops-engineer Design, optimize, and debug CI/CD pipelines. GitHub Actions and GitLab CI patterns. Use for pipeline work.

incident-response-engineer Operational incident response for triage, containment, communications, recovery, and postmortems. Use when coordinating outages or service degradation.

changelog-writer Generate changelogs, release notes, and migration guides from git history. Parse conventional commits. Use for releases.

View Full SKILL.md

SKILL.md

---
name: release-pipeline-architect
description: >-
  Release workflow architecture for versioning, artifact promotion, rollout
  safety, and rollback design. Use for release pipelines. NOT for generic CI
  tuning or infrastructure.
argument-hint: "<mode> [target]"
license: MIT
metadata:
  author: wyattowalsh
  version: "1.0.0"
---

# Release Pipeline Architect

Design release pipelines that move one immutable artifact through test, staging,
and production with clear gates, rollout strategy, and rollback procedure.

**Scope:** Release orchestration after code is ready. NOT for infrastructure
provisioning (infrastructure-coder), generic CI job optimization
(devops-engineer), or release-note writing (changelog-writer).

## Canonical Vocabulary

| Term | Definition |
|------|------------|
| **release candidate** | A versioned build proposed for promotion |
| **artifact** | The immutable build output promoted across environments |
| **promotion** | Moving the same artifact to the next environment |
| **gate** | A manual or automated approval checkpoint |
| **provenance** | Evidence tying an artifact to source commit, build, and checks |
| **rollout** | The production exposure strategy: all-at-once, canary, or phased |
| **rollback point** | The last known-good release that can be restored safely |
| **freeze window** | A period where changes are limited to release-critical work |
| **hotfix lane** | A minimal path for urgent production repairs |

## Dispatch

| $ARGUMENTS | Mode |
|------------|------|
| `design <requirements>` | Design a release pipeline and operating model |
| `review <pipeline or runbook>` | Audit an existing release flow |
| `cutover <release>` | Plan the release-day sequence and handoffs |
| `hotfix <incident>` | Design an emergency release lane |
| `checklist <release type>` | Produce a release readiness checklist |
| Natural language about release workflows | Auto-detect the closest mode |
| Empty | Show the mode menu with examples |

## Mode Menu

| # | Mode | Example |
|---|------|---------|
| 1 | Design | `design weekly SaaS release with staging and canary prod` |
| 2 | Review | `review .github/workflows/release.yml` |
| 3 | Cutover | `cutover v2.8.0` |
| 4 | Hotfix | `hotfix rollback path for broken payments deploy` |
| 5 | Checklist | `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

| File | Read When |
|------|-----------|
| `references/rollout-decision-matrix.md` | Choosing between all-at-once, canary, phased, and blue/green rollout patterns |
| `references/provenance-evidence-checklist.md` | Defining artifact identity, approval evidence, release records, and post-release proof |
| `references/failure-modes.md` | Reviewing an existing pipeline for structural release risks and rollback gaps |
| `references/runbook-templates.md` | Producing cutover runbooks, hotfix lanes, and binary release-readiness checklists |

## Scope Boundaries

**IS for:** release trains, approvals, environment promotion, rollout strategy, rollback design, cutover sequencing.

**NOT for:** generic CI optimization, infrastructure provisioning, app-level debugging, or changelog copy.

Download from GitHub

Resources

Skill Catalog Browse custom and external skills.

CLI Reference Install and manage skills.

agentskills.io The open ecosystem for cross-agent skills.

---

View source on GitHub