Use migration-plan

Generate a phased migration or rollout plan (schema change, API version, datastore swap, platform move, auth-provider switch)

Generate a phased migration or rollout plan (schema change, API version, datastore swap, platform move, auth-provider switch) — expand→migrate→contract by default, every phase reversible or its point of no return named, observable gates between phases, idempotent backfill with parity checks.

Reach for it when the user needs a migration plan, cutover plan, rollout strategy, or asks "how do we get from X to Y without downtime".

Install it

npx skilldrop-cli install migration-plan                 # Claude Code, your user folder
npx skilldrop-cli install migration-plan --project       # Claude Code, this repo
npx skilldrop-cli install migration-plan --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Plan the migration for this schema change"
• "How do we roll this datastore swap out safely with no downtime?"
• "Give me a phased expand-migrate-contract plan for this API version"
• "We're switching auth providers — plan the cutover and rollback"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Design the new database schema and its indexes"
• "Split this migration work into user stories"
• "Write the runbook for the on-call team"

If another skill answers instead, ask for this one by name: "use migration-plan".

Check what you get

A good result:

• Every phase is reversible, or is the named point of no return. A reader can answer "how do we get back from here?" for any row in the plan.
• Every gate is observable with a bake time. "Looks good" is not a gate; "error rate ≤ baseline +0.1% for 48h and parity job green" is.
• One change per phase. A failed phase implicates exactly one change — that's what makes rollback decisions fast.
• Backfill is idempotent, resumable, rate-limited, parity-checked — all four stated, none implied.
• The contract phase has a date, an owner, and a gate. Plans that end at "100% on new path" are unfinished.
• Rollback steps are tested, not asserted. Each rollback names when it was (or will be) rehearsed; an unrehearsed rollback is a hypothesis.

Use something else when

• A change deployable in one reversible step — normal deploy, no plan needed
• Choosing the target ("should we move to DynamoDB?") — this skill starts after the decision
• The test depth itself — emit gates here, hand verification design to test-plan-generator
• Organizational/process migrations with no system state — different problem

Where a loop runs it

• Stage plan of the modernize loop
• Stage plan of the release loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: council-review, test-plan-generator

Edit this page on GitHub · View source