writing plans

• header (goal, architecture, stack, spec link) plus global constraints copied verbatim from the spec — every task inherits them.
• tasks sized to one deliverable with its own verification cycle.
• steps of one action each: write the failing test, run it, write minimal code, run it, commit.
• every task declares its files (exact paths) and interfaces (consumed from earlier tasks, produced for later ones, with signatures). executors see only their own task; the interfaces block is how they learn the neighbors' names.

plans fail through placeholders: "Add appropriate error handling," "similar to Task N," "TBD" — each delegates a judgment call to an executor lacking the context to make it, and that is where implementations drift.

• no placeholders — actual code, actual paths, actual commands.
• DRY, YAGNI, TDD, frequent commits.
• self-review after writing: spec coverage, placeholder scan, type consistency across tasks.
• the spec travels with the plan; the plan argues from it.

when a spec or requirement set exists for multi-step work, before touching code. the plan is the last artifact a human shapes alone and the first an executor can run mechanically.

bad

task 3: add appropriate validation

the executor must invent schema ownership, failures, and verification. shipped behavior depends on who executes the plan, not on the approved spec; the drift is invisible at review (each local choice looks reasonable) and surfaces only when the pieces meet.

good

task 3: add CreateWorkflowInputSchema in contracts/workflow; parse at the route;
verify malformed input returns the stable correction diagnostic

exact path, boundary, behavior, and command-level proof. with no judgment calls left in the steps, any executor — human or subagent, zero codebase context — produces the same implementation, and each verification is a mechanical check, not an interpretation. that is what makes handoff cheap: planning effort converts directly into unsupervised execution.

executing plans · specification first