project-migration
Project Migration
Treat the request as project migration, repository migration, or engineering-system migration by default. Optimize for business continuity, behavior parity, rollback safety, and controlled scope rather than opportunistic rewrites.
Do not use this skill when the user mainly wants a project handover or successor-facing takeover document without a real migration goal. In those cases, prefer project-handover-generator.
Workflow
Use this default phase order unless the user explicitly narrows the request:
intake -> audit -> map -> diff -> plan -> pilot -> execute -> verify -> cleanup
If the user does not specify a phase, complete only the current phase, then stop and present outputs, status, risks, and the recommended next phase.
If the user specifies a phase, complete the minimum prerequisite phases needed to produce a credible result. If phase artifacts already exist, update them instead of restarting.
If the user changes an earlier phase after later-phase work already exists, revise the earlier phase first and then check all affected downstream phases.