writing-migration-plans

Structure migration plans as tracking issues with chained execution links and one approval pass.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/missingbulb/GoogleCalendarEventCreator --skill writing-migration-plans-missingbulb
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: writing-migration-plans
Source: https://github.com/missingbulb/GoogleCalendarEventCreator/tree/main/.claudinite/shared/packs/basics/skills/writing-migration-plans
Command: npx skills add https://github.com/missingbulb/GoogleCalendarEventCreator --skill writing-migration-plans-missingbulb

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Migration and implementation plans often stall mid-run because phases are ordered by topic rather than by what blocks, scattering human gates across the whole run and leaving cleanup steps permanently deferred. ## Core Features & Use Cases - Two-deliverable discipline: Keeps the design doc limited to end state and rationale while the plan lives only in an append-only tracking issue, never a repo document. - Three-block ordering: Sorts every step into out-of-band setup, a single collapsed review gate over a full PR stack, and a chain of queued execution links armed on each other. - Failure-resilient chaining: Files each execution step as a sub-issue with Blocked-by edges, predicted diff scopes, automerge policies, and validation-on-read so the chain survives parked PRs, red CI, or unmerged closes. - Use Case: When about to write a DESIGN.md or phased rollout plan, use this to draft the plan, get owner approval of its shape, and file the entire chain of issues before any work starts. ## Quick Start Ask the AI to draft a migration plan for your initiative following this skill, producing a tracking issue with phases, a dependency graph, and per-link automerge policies before filing any issues.

Frequently Asked Questions about writing-migration-plans

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a migration plan that does not stall mid-run?▼

Order phases by what blocks rather than by topic: front-load all out-of-band setup, write all code including cleanup as one PR stack for a single approval, then chain execution steps as queued issues each armed on the previous step's verified result.

Where should a migration plan document live?▼

The plan lives in a tracking issue, never as a plan document committed to the repo. The design doc carries only the end state with rationale and alternatives; the issue is checkable, append-only, and dies with the work.

How do I handle legacy compatibility shims during a migration?▼

Ship the tolerance with an advisory reaching its holders, write the removal code in the same approved stack, and schedule its merge on a time window rather than a census. State at the tolerance site which chain link removes it.

What happens when a chained PR is closed unmerged?▼

Each link's brief opens by reading the previous link's artifact on main, such as a field or export. If absent, the run converges as an action naming the unmerged link instead of building on air, since the chain advances on validation, not closure.

When should destructive cleanup steps be scheduled in a migration?▼

Write and approve destructive steps with the full stack, but defer their merge until after the cutover is observed working. The merge becomes a link in the chain armed on the cutover, never a later cleanup phase.