Skill · Release
Rollback Plan Writer
Write a tested rollback and forward-recovery plan for a release, including triggers, commands, compatibility constraints, data handling, verification, ownership, and stop conditions. Use before high-risk deploys, schema or configuration changes, dependency upgrades, model or provider migrations, feature launches, and any release where 'just redeploy the old version' is incomplete or unsafe.
User-invocablev1.0.0
Updated Aug 4, 2026npx agentscamp add skills/rollback-plan-writerInstall to ~/.claude/skills/rollback-plan-writer/SKILL.md
Writes an executable release recovery plan: defines objective rollback triggers, inventories application, schema, data, config, cache, queue, and external compatibility, selects rollback versus forward fix, provides verified commands and owners, protects irreversible writes, and specifies health checks and observation windows. Guessed commands and 'redeploy previous' are rejected.
Write a plan responders can execute under pressure. Verify commands against repository and deployment configuration; label anything that cannot be confirmed.
Workflow
- Define release scope. List application artifacts, database migrations, configuration, feature flags, secrets, caches, queues, scheduled jobs, infrastructure, APIs, models/providers, and external dependencies changing together.
- Set objective triggers. Use error rate, latency, correctness, data integrity, SLO burn, queue depth, or business metrics with thresholds and observation windows. Name who declares rollback.
- Check compatibility in both directions. Confirm old code can run against new schema and data, new code can run during partial rollout, events remain readable, and configuration and secrets can be restored. Identify the point after which rollback becomes unsafe.
- Choose recovery paths. Define fast disable or feature-flag containment, application rollback, configuration rollback, traffic shift, and forward fix. State when each applies and when to stop trying it.
- Protect data. Describe dual-write or expand-contract phases, write freezes, backups or exports, reconciliation, queued-message handling, and irreversible effects. Never invent a down migration for data that cannot be reconstructed.
- Write exact commands. Mine workflow files, deployment manifests, runbooks, and scripts for artifact IDs, environments, namespaces, revisions, and flags. Include expected output and the next decision.
- Assign roles and communication. Name release lead, executor, verifier, database or platform owner, and communication owner. Include escalation thresholds and stakeholder channels.
- Verify recovery. Use the same health and business checks as the release gate. Define how long metrics must remain healthy, how data is reconciled, and which temporary containment steps must be removed.
- Rehearse. Dry-run commands in a safe environment or tabletop the sequence. Record untested assumptions and block the release when the only recovery path is speculative.
WARNING
A rollback command that has not been checked against the current deployment configuration is a hypothesis. Label it unverified and test it before approving the release.
Output
Create a Markdown rollback plan containing:
- release inventory and compatibility matrix
- trigger table with threshold, observation window, and decision owner
- containment, rollback, and forward-recovery decision tree
- exact commands with expected results and stop conditions
- database, event, cache, and external-side-effect handling
- roles, escalation, and communication
- verification and observation checklist
- rehearsal results, untested assumptions, and rollback cutoff point
Frequently asked questions
- Why is redeploying the previous version not always a rollback plan?
- The new release may have changed database shape, written data the old code cannot read, emitted incompatible events, warmed a new cache format, rotated secrets, or changed a third-party contract. The plan must prove backward compatibility across every changed state.
- When is forward recovery safer than rollback?
- When the release made irreversible or expensive-to-reverse state changes, external consumers already depend on the new contract, or returning old code would corrupt new data. In those cases, disable exposure, preserve state, and deploy a bounded corrective change.
Related
- 10 Best Claude Skills for DevOps and SREUse Claude skills for incidents, rollbacks, SLOs, alerts, dashboards, logs, traces, containers, CI, and safer releases.
- Canary Release PlannerDesign a canary / progressive rollout so a bad release reaches 1% of users instead of 100% — staged traffic with bake times, gating metrics compared against the concurrently-running stable baseline, and automated promote-or-rollback. Use when shipping a risky change, when you want automatic rollback on regression, or when moving off all-at-once deploys.
- Migration WriterWrite a safe, reversible, zero-downtime database migration using expand-contract — add the new shape, backfill in batches, switch reads/writes, then drop the old — so every deploy stays compatible with the running app version. Use when adding or changing schema on a live system, renaming/dropping a column, adding NOT NULL or a foreign key on a large table, or when a migration risks locks, table rewrites, or an unrevertable step.
- Version BumperBump the project version everywhere it lives in one consistent pass — package.json, lockfile, nested/CLI package manifests, version constants, README badges, docs — then roll the changelog's Unreleased section under the new version and stage an annotated git tag. Use when you've already decided the new version (X.Y.Z or a pre-release like -rc.1) and need every artifact updated to the same value without drift, or before cutting a release.
- Runbook WriterWrite an operational runbook a half-asleep on-call engineer can execute at 3am — scoped to ONE alert, leading with how to confirm the problem, the copy-pasteable mitigation that stops user pain, then diagnosis, escalation, and verification. Use when an alert has no documented response, after an incident exposed a missing procedure, or when standing up on-call for a service.
- SemVer AdvisorDecide the correct semantic-version bump — major, minor, or patch — by diffing a release range, mapping the changes onto the public API surface, and classifying each as breaking, additive, or a fix. Use before cutting a release when you are unsure whether changes are breaking, when a teammate proposes a bump you want to sanity-check, or when a behavior change has no signature change and you need to know if it is still breaking.