writing-plans

Start from a spec or requirements document, map out which files will be created or modified, then decompose the work into bite-sized TDD tasks. Each task lists exact file paths, complete code, test commands with expected output, and a commit step.

Each step should be one action taking 2-5 minutes: write the failing test, run it to confirm failure, implement minimal code, verify it passes, then commit. Steps must contain actual code and exact commands, never placeholders like TODO or add error handling.

Split when the spec covers multiple independent subsystems. Each plan should produce working, testable software on its own, so one plan per subsystem keeps scope manageable and execution verifiable.

Run a self-review after writing: check each spec requirement maps to a task, scan for placeholder patterns, and confirm type and method names stay consistent across tasks. Fix issues inline and add tasks for any uncovered requirements.

Plans assume a finished spec exists, so they are not suited for exploratory work where requirements are still unclear. They also require discipline to keep code blocks complete, since vague steps cause implementers to get stuck.