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, CLI, generator, or version, run [[research]] — a plan built on a hallucinated command or 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.

Before you plan to build any non-trivial functionality — parsing, dates/timezones, auth, retries, HTTP, validation, state machines, queues, crypto, file formats — run [[library-first-development]] to decide build-vs-adopt at planning time. This is a planning-time decision, not an implementation-time one: "adopt library X" versus "hand-roll it" produces entirely different tickets, dependencies, and acceptance criteria. Discovering mid-fan-out that a ticket should have been a npm install is N agents of wasted work. Vet the candidate here, then either the chosen library is a stated dependency of the dependent tickets or its evaluation is its own earlier ticket.