-
Freeze the intent. What does the user want to start? What outcome would make the work worth
doing? What must not be broken? What is still unknown?
-
Make the goal verifiable. Rewrite vague activity into a target outcome. Define the boundary
(included, excluded, deferred). Choose the strongest available evidence source — test, metric,
review, artifact, command, behavior, user signal, or trace — and a clear pass/fail rule with a
confidence note, and name the judgment owner — who or what is authorized to declare it done.
Quantify when useful, but do not invent fake metrics. If one intent contains
multiple goals, split them.
-
Convert the goal into a goal document. Record assumptions and unresolved decisions, identify
affected surfaces (docs, code, schema, API, UI, tests, workflows, links), and define what "ready
to execute" means.
-
If rewriting an existing plan, re-anchor it to the target. Extract the plan's phases, todos,
assumptions, dependencies, and highlighted focus points. Diagnose drift — goal drift, phase
drift, validation drift, compatibility drift, cleanup drift — and decide per item what to keep,
reorder, merge, or remove. Move high-risk, high-uncertainty, or high-leverage work earlier unless
dependencies forbid it. Keep old wording only when it remains accurate under the new target.
-
Split into phases. Each phase should produce a reviewable state. Split by learning, risk
reduction, user-visible value, system boundary, dependency order, vertical slice, decision
boundary, or validation boundary — never by department, file type, arbitrary chronology, or topic
heading. Avoid phases that only say "implement X" without proof.
-
Define phase rules. For each phase, state what is allowed, what is explicitly not allowed yet,
what compatibility or migration rule applies, what documentation update is required, and what
validation must pass before moving on. Concrete patterns to draw from:
- Do not touch implementation until the target doc is updated.
- This phase may rename internal callers directly; no compatibility shim unless a public contract exists.
- This phase may only change docs and tests, not production code.
- This phase exits only when the command/test/check passes.
- Stop if a todo requires a product decision not present in the goal document.
-
Create todos with action + surface + proof (see template). Make them concrete enough to
execute without guessing, mark dependencies and blockers that affect order, and keep unrelated
cleanup out unless the phase goal requires it.
-
Add progress management when execution will continue across phases or sessions. Use one
phase checklist with nested proof-bearing todos. Mark a phase complete only after its exit proof
passes, and record any reprioritization instead of silently following stale order. Omit this
machinery for a short one-session plan.
-
Dry-run the route. Walk the phases in order without executing them; look for missing
prerequisites, circular dependencies, vague todos, and unverified assumptions; revise the goal
document before any real work. This step is what separates a goal document from generic planning.
-
Decide whether to Go. If the route is coherent, execution can start. If it carries unresolved
decisions, resolve them with the right skill first (see below) and re-run the dry-run.
