Writing a change plan

DISRESPEC-SPINE: One fact once. No filler, repeated source material, empty sections, or chat restatement; after successful creation return only clickable artifact links, except for blockers, failed creation, incomplete verification, or irreversible-action confirmation.

A spec answers "what should the system do?"; a change plan answers "how does the codebase change safely?" Write one when the work is primarily structural — it spans modules, must preserve behavior while touching risky code, needs sequencing, or will land as a diff too large to interpret without a map. Skip it for an obvious bug fix or a small cleanup.

A change plan has these sections, in order: Baseline · Target · Preservation guarantees · Transformation waves · Cutover / rollback · Task split (when needed). The plan sits beside the spec it serves. This skill is how the plan gets created. When the deterministic checker is available, run suspec check <path>; otherwise apply its structural checks by hand.