writing-planslisted

# Writing plans **Trigger.** The work ahead is larger than one obvious edit: several files, an unclear boundary, a migration, a feature with sub-parts, or anything you would otherwise start by "having a look around and seeing". > **Reference material** (the plan template, sizing heuristics, worked > examples of a bad plan rewritten, and how to revise mid-execution): see > `reference.md` in this directory. ## The rule > **A step is done when something observable changes. If you cannot say what > would be observed, it is not a step — it is a wish.** The purpose of a plan is not to look organized. It is to (a) surface the decisions and unknowns *before* they are expensive, and (b) produce checkpoints where someone can tell whether progress is real. ## Before planning: resolve the scope Do not plan against a guess. Spend the first pass on the request itself: 1. **Restate the goal** in one sentence, in terms of the observable outcome. 2. **List the unknowns.** Anything where two readings lead to materially different work. 3. **Decide or ask.** For a routine judgment call, decide and record the assumption in the plan. For a fork that would waste the work if wrong, ask now — not after step 4. 4. **Establish the baseline.** What currently works? Run the tests *before* changing anything, so a later failure is attributable. A plan built on an unresolved ambiguity is a plan to do the work twice. ## Writing the steps Each step gets three things: | Field | Requirem