plan
Planning
A plan is finished when an agent fleet could drain it without you in the room: every ticket is a single unit of work, spawnable in parallel, with acceptance criteria that say exactly when it's done, and a dependency graph that makes the fan-out order computable rather than guessed. Planning is the work — the tickets are just its output. Coast on the planning and you pay for it N times over, once per agent that picks up an under-specified ticket.
The discipline
Don't decompose first. Decomposition is step 5. Walk the work down to bedrock, then cut it into pieces.
1. Frame it: bug or change?
- A bug, regression, "it's broken / slow / flaky" → you cannot plan a fix you haven't diagnosed. Run [[diagnose]] first. Its output — the root cause, the feedback loop, the correct test seam — is the input to the rest of planning. Planning around a symptom plans the wrong work.
- A feature or change → go to step 2.
2. Understand before you cut
Read the spec and the actual code — not your memory of the code. Map the real dependency graph: what must exist before what. For any unfamiliar library, API, or version, run [[research]] — a plan built on a hallucinated API signature is N tickets of rework. Name the unknowns explicitly; a named unknown is a research ticket, a buried one is a mid-implementation stall.