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. Use when the user needs a migration plan, cutover plan, rollout strategy, or asks "how do we get from X to Y without downtime".
Pack dev-teamTier standardJob Design the systemv0.1.1
In Claude Code, with the dev-team plugin installed, invoke it as:
/dev-team:migration-plan
Try it
A realistic prompt from the skill's acceptance evals:
Plan the migration from our single-tenant Postgres schema to a multi-tenant one, with no downtime.
What a good result looks like
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.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 68% of its checks, against 53% without it, and a blind judge preferred the agent without it. How skills are checked
18 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
The plan is phased expand-migrate-contract by default
Every phase is reversible, or is explicitly named as the point of no return — a reader can answer 'how do we get back from here?' for every phase
Every gate is observable with a bake time and a threshold, not 'looks good'
Each phase carries exactly one change, so a failed phase implicates one thing
Rollback steps are stated per phase rather than as a single end-of-plan afterthought
The plan works within the legacy system's limits: no dual-write, change-data capture or DonorTrack API is assumed; it relies on the nightly full export (with repeated loads, upserts by donor_id, or a freeze window)
Flags that TEMP-TRAVEL and MED-REVIEW have no mapping in Haemora, contradicting the IT lead's '1:1' note, and treats this as something to resolve before any donor is registered in the new system, because a deferred donor could otherwise be bled
Flags that the trial import does not add up: 401,200 rows minus 9,300 merged duplicates is 391,900, but 395,400 were loaded, despite the 'SUCCESS' result
Handles records from the mobile vans that reach DonorTrack up to 3 days after an export or after cutover
Treats 1 December as conditional on checks passing, and says from what point going back to DonorTrack 4 is no longer possible and how to go back before then
Does not present invented figures or system capabilities as if they came from the input
Is no more than two pages
Gives an ordered set of steps covering entering all future appointments into the app and checking them against the paper book before relying on it
Sets a clear switch-over day, or a short period where both are kept, with one of them named as the one that counts
Includes a fallback if the app fails (for example keeping the paper book, or a printout of upcoming appointments)
Fits in half a page
Uses plain language for a practice manager rather than software jargon
Does not invent BookWell features, prices or settings
When it should and shouldn't activate
Should activate:
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
Should leave to another skill:
Design the new database schema and its indexes
Split this migration work into user stories
Write the runbook for the on-call team
Write an ADR recording why we chose this datastore