Release Planner

Purpose

Use this skill to produce a complete, actionable release execution plan — the final stage artifact that bridges technical deployment readiness with operational coordination and stakeholder communication.

This skill is not a deployment checklist. It is a first-class planning artifact that integrates rollout waves, migration sequencing, risk mitigation, validation checkpoints, rollback strategy, observability, and communication into a single coherent plan.

This skill is domain-generic. It must work for any software release without embedding project-specific context, vendor names, or product names.

When to Use

Use this skill when the user asks to:

• Design a rollout strategy for a production release.
• Plan phased release waves with validation gates between each wave.
• Sequence database migrations and data migrations alongside application releases.
• Define a canary or progressive rollout with traffic segmentation.
• Build a rollback plan with decision criteria, procedures, and ownership.
• Produce a go/no-go checklist with measurable criteria.
• Create a release communication plan for stakeholders.
• Map monitoring and observability checkpoints to release waves.
• Assess blast radius and backward/forward compatibility risks.
• Connect deployment sequence, migration plan, and rollout waves into one artifact.

Do not use this skill for application architecture, source-code implementation, product strategy, or project scheduling. Keep the output at release execution planning level.

Core Operating Rules

1. Treat deployment sequence, migration plan, and rollout waves as first-class artifacts. Each serves a different purpose and must be planned separately, then integrated.
2. Never plan a release without a defined rollback strategy. If rollback is impossible or would cause data loss, the plan must flag this as a blocking constraint before any wave proceeds.
3. Blast radius assessment drives wave sizing. The smaller the blast radius per wave, the smaller the impact of a failed release.
4. Backward/forward compatibility is a prerequisite for wave sequencing. Incompatible changes must be resolved before wave planning begins.
5. Observability must be active before the first user is exposed. If monitoring cannot detect a failure within the observation window, the wave must not proceed.
6. Data migration safety is non-negotiable. Any wave that could leave data in an inconsistent state must be treated as higher risk and gated accordingly.
7. Go/no-go criteria must be measurable, not subjective. Use concrete thresholds: error rate delta, latency p99, business KPI deviation, or coverage percentage.
8. Communication plan is a first-class artifact, not an afterthought. Stakeholders must know when they will be informed, through which channel, and what the trigger conditions are.

Release Anatomy: Five First-Class Artifacts

A complete release plan must contain all five of these artifacts:

Artifact 1: Deployment Sequence

Definition

The ordered list of deployment steps required to put the release into production. Each step documents what is deployed, what dependencies it has, and what state the system is in after the step.

Principles

• Deploy consumers before producers for backward-compatible changes (new schema first, then new code that writes to it).
• Deploy producers before consumers for forward-compatible changes (new code first, then new schema).
• Database changes are always first or always last — never interleaved with application code changes unless using the expand/migrate/contract pattern.
• Feature flags enable decoupling of deployment from release. Use them to hide unfinished features behind a kill switch.

Deployment Order Template

## Deployment Sequence

| Step | Component | Action | Pre-condition | Post-condition | Rollback |
|---|---|---|---|---|---|
| 1 | Database schema | Apply add-only migrations | Schema version N | Schema version N+1 (additive only) | Revert migration |
| 2 | Configuration | Deploy feature flag config | Flag off | Flag available in off state | Revert flag config |
| 3 | Application (read-only services) | Deploy new version | Old version serving reads | New version serving reads, no new writes | Redeploy old version |
| 4 | Application (write services) | Deploy new version | Write path on old version | Write path on new version | Redeploy old version |
| 5 | Migration completion | Enable new schema paths | Old and new paths both functional | New path exclusive | Revert migration + redeploy old app |

Artifact 2: Migration Plan

Definition

The plan for safely evolving data and schema across release waves. Covers database schema changes, data transformations, and any dual-write or dual-read patterns.

The Expand/Migrate/Contract Pattern

Use this three-phase pattern for any schema change that would otherwise be breaking:

Phase 1 — Expand (add new but keep old):

• Add new column/table/index.
• Keep old column/table/index.
• Application writes to both old and new.
• Background process migrates existing data.

Phase 2 — Migrate (verify data):

• Verify migration completed with data integrity checks.
• Run reads against new path; confirm results match old path.
• Promote new path as primary.

Phase 3 — Contract (remove old):

• Stop writing to old column/table.
• Remove old column/table in a subsequent release.

Migration Safety Heuristics

Migration Plan Template

## Migration Plan

### Schema Changes
| Step | Change | Compatibility | Wave | Rollback |

### Data Migrations
| Step | Query/Job | Volume | Blocking? | Batch Size | Wave |

### Dual-Write / Dual-Read Pattern
| Phase | State | Application Behavior |
|---|---|---|
| Expand | Both schemas writable | Write to old and new |
| Migrate | New primary, old verify | Read both; compare; log mismatches |
| Contract | New exclusive | Stop writing to old |

Artifact 3: Rollout Waves

Definition

The progressive increase in user or traffic exposure across defined waves. Each wave is gated by validation checkpoints before the next wave begins.

Wave Sizing Heuristics

Segmentation Strategy

Choose the segmentation that best matches the risk and the system's user topology:

• Percentage of users — simplest, uniform risk distribution.
• Geographic region — use when latency or data residency matters.
• User cohort — internal users, beta users, premium users.
• Traffic weight — route X% of requests to new version via load balancer or service mesh.
• Feature flag — enable new feature for a specific flag rule.

Wave Gate Criteria

Before each wave advances, all of these must be true:

Rollout Waves Template

## Rollout Waves

### Wave Definition
| Wave | Segment | Size | Trigger | Hold Duration |

### Traffic Segmentation
| Segment | Strategy | Size | Instruments |

### Wave Gate Criteria
| Gate | Metric | Threshold | Observation Window |
|---|---|---|---|

Artifact 4: Risk Mitigation

Blast Radius Heuristics

Compatibility Risk Classification

Risk Mitigation Template

## Risk Mitigation

### Blast Radius by Wave
| Wave | Change | Blast Radius | Affected Components | Mitigation |

### Compatibility Risks
| Risk | Type | Wave Affected | Resolution |

### Data Migration Risks
| Risk | Volume | Mitigation |
|---|---|---|

Artifact 5: Rollback Strategy

Definition

The documented, tested procedure for reverting each wave. Includes decision criteria, rollback triggers, step-by-step procedures, and ownership.

Rollback Trigger Conditions

Define explicit, measurable triggers — never subjective:

Rollback Procedure Template

## Rollback Strategy

### Rollback Triggers
| Trigger | Metric | Threshold | Owner |

### Rollback Procedures
| Wave | Step | Action | Owner | Time Budget |

### Rollback Ownership
| Role | Responsibility |
|---|---|

Monitoring and Observability by Phase

Pre-Release Baseline

Establish baseline metrics for all critical paths before wave 1:

• Error rate (5xx), latency (p50, p95, p99), throughput (requests/second).
• Business KPIs relevant to the release.
• Database query performance for affected schemas.

Monitoring Checkpoints Per Wave

Canary Analysis (Automated)

When using automated canary analysis tools (Argo Rollouts, Flagger, Spinnaker):

• Define evaluate criteria: error rate threshold, latency threshold.
• Set analysisTemplate with minimum weight and step count.
• Configure autoRollback on analysis failure.

Communication Plan

Stakeholder Communication Template

## Communication Plan

### Pre-Release
| When | Audience | Channel | Message |
|---|---|---|---|
| T-72h | Engineering leads | Async / Slack | Release scope, wave plan, rollback triggers |
| T-48h | Product / stakeholders | Email / async | Release date, wave timeline, success criteria |
| T-24h | Operations / on-call | Sync / briefing | Monitoring plan, escalation path, contacts |

### During Release
| When | Audience | Channel | Trigger |
|---|---|---|---|
| Before each wave | Release lead | Direct | Go/no-go decision |
| Wave gate pass | Stakeholders | Channel per audience | Gate closed |
| Rollback trigger | Incident response | Pager / Slack | Rollback initiated |

### Post-Release
| When | Audience | Channel | Message |
|---|---|---|---|
| Post-wave 1 | All stakeholders | Email / Slack | Wave 1 complete, metrics summary |
| Full rollout | All stakeholders | Email / Slack | Release complete, metrics summary |
| Post-incident | Stakeholders + leadership | Incident report | Root cause, impact, remediation |

Go/No-Go Criteria

Pre-Wave Go Checklist

For each wave, all of the following must be green before proceeding:

Input Artifact Mapping

The skill adapts based on what input artifacts are provided:

If no artifact is provided, ask the user to specify the release scope before producing the plan.

Output Structure

Use this structure for the complete release plan:

# Release Plan: <Release Name>

## 1. Release Overview
- **Scope:** <what is being released>
- **Risk Profile:** <Low / Medium / High / Critical>
- **Wave Count:** <N waves>
- **Communication:** <stakeholder plan summary>

## 2. Deployment Sequence
[Artifact 1]

## 3. Migration Plan
[Artifact 2]

## 4. Rollout Waves
[Artifact 3]

## 5. Risk Mitigation
[Artifact 4]

## 6. Rollback Strategy
[Artifact 5]

## 7. Monitoring and Observability
[Monitoring checkpoints by wave]

## 8. Communication Plan
[Stakeholder communication template]

## 9. Go/No-Go Checklist
[Per-wave go/no-go criteria]

## 10. Integration Summary
<One paragraph: how all five artifacts connect into a coherent release story>

Quality Bar

Before presenting the release plan, verify:

• All five first-class artifacts are present and fully developed.
• Migration plan uses expand/migrate/contract for any breaking schema changes.
• Rollback strategy exists for every wave, with measurable trigger criteria.
• Go/no-go criteria are measurable (concrete thresholds, not subjective).
• Blast radius is assessed for every wave; wave sizing reflects blast radius.
• Backward/forward compatibility is verified before wave 1; incompatible changes are flagged as blocking.
• Monitoring checkpoints are defined per wave and observation windows are specified.
• Communication plan covers pre-release, each wave transition, and post-release.
• The skill output is written in English.
• No project names, client names, or unnecessary concrete technologies appear in the output.
• Deployment sequence and migration plan are consistent with each other (no step in the sequence contradicts the migration plan).

Present Results to User

Lead with the release risk profile and wave count. Present the wave plan first so the user sees the progression from low exposure to full rollout. Then present the rollback strategy so the user understands the safety net before reading the deployment sequence. Highlight any blocking items (incompatible changes, missing observability, absent rollback capability) as these prevent the plan from being actionable. If the release is high-risk, recommend reducing wave 1 size or adding an internal-only wave before external exposure.

Troubleshooting

• User provides no release scope: Ask for the release scope, or at minimum the components being released and the target date.
• Breaking schema change identified: Flag this as a blocking constraint. The release cannot proceed safely until backward-compatible migration path is designed using expand/migrate/contract.
• Rollback impossible (data migration already committed): Flag this as a critical risk. The plan must document that rollback would cause data loss and is therefore not an option; mitigation must be in the migration plan itself.
• No observability for critical paths: Block wave 1 until monitoring is active. A release without observability is a blind release.
• Wave sizing is uniform (all waves same size): This is a smell. High-risk changes should have smaller early waves. If all waves are equal, the plan is not optimized for blast radius.
• Communication plan missing for wave transitions: Every wave transition is a stakeholder touchpoint. If the user has not defined who needs to be informed and when, the communication plan is incomplete.
• No baseline metrics available: Establish baseline before wave 1. Without baseline, go/no-go criteria cannot be evaluated objectively.