plan-change

Plan the change before writing code

Implementing without a plan is how a ticket drifts: you discover scope mid-edit, touch files the ticket never asked about, and finish with a diff no one can map back to the ACs. A short, written plan fixes the target before you move — you commit to a scope and a verification path, then execute against it (and later self-review against it).

The plan is a tool, not a deliverable. Keep it tight: a few lines per AC, not a design doc. Its only job is to make scope and proof explicit before the first edit.

Steps

1. Re-read the ticket and its ACs. Call get_ticket (Dispatch MCP). The acceptance criteria — not your sense of the task — define what "done" means. Hold each one.
2. Consult memory so the plan respects conventions. Call search_lore (Memory MCP) for relevant conventions, ADRs, test commands, naming rules, and ownership boundaries. A plan that ignores an existing convention produces a correct-but-rejected PR.
3. Map each AC to a concrete change. For every acceptance criterion, write a line or two:
   • which files you will edit or add (real paths — locate them now, not mid-edit);
   • what the edit is in one phrase (the actual change, not "implement the feature");
   • what test proves it — the specific test you'll add or run, and the command that runs it. Every AC needs a verification path before you start, not after.
4. Name what's out of scope — explicitly. List the tempting-but-excluded: refactors the ticket doesn't need, adjacent bugs, files you will not touch. This is the line you hold during implementation and check at self-review. If an AC has no clear in-scope change, that's a gap to clarify — don't paper over it.
5. Sanity-check the plan against the ACs. Does executing it satisfy every AC? Is any AC unaddressed, or any planned change unmapped to an AC? Tighten until the plan and the ACs line up one-to-one.
6. Output the plan, then execute it. State it briefly (per-AC change + proof, plus the out-of-scope list) and proceed to create-branch → implement. Keep the plan to hand — self-review checks the finished diff against it.