Rollback Plan Skill

Turns "we'll roll back if it goes bad" into a plan somebody unfamiliar with the change can execute under pressure. The single job: make the reverse of the change knowable, verifiable, and boring.

Working from a brief

Deliver the full plan even from a thin brief — infer and label assumptions (never invent service names, dashboard URLs, commit SHAs, or migration IDs). If a required input is missing, ask once, then move on with unknown — confirm before rollout placeholders.

Required Inputs

Ask for (if not already provided), else label as unknown:

• The change — what's shipping, service(s) affected, blast radius.
• How it ships — deploy pipeline, feature-flag key, migration ID, config path.
• Rollout shape — big-bang, staged (X% → Y% → 100%), canary, region-by-region.
• Data implications — does it write new schema/data, change the meaning of existing columns, backfill, encrypt-in-place, delete? Reversible in-place or one-way?
• Downstream consumers — services / queues / clients that read the changed contract.
• Trigger conditions — the SLIs / dashboards / alerts that would tell us it's bad (be specific: metric, threshold, duration).
• Who owns the decision — the human who can pull the trigger, and their escalation path if unreachable.