writing-plans

Map out the file structure first, then decompose the work into tasks where each step is one 2-5 minute action: write a failing test, verify it fails, implement minimal code, verify it passes, and commit. Include exact file paths and complete code in every step.

Each task should target one component with clearly listed files to create, modify, and test. Steps follow the red-green-commit cycle with exact commands and expected output, and no placeholders like TODO or 'add error handling' are allowed.

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 reviewable.

Run a self-review checking three things: every spec requirement maps to a task, no placeholder patterns remain, and type and method names are consistent across tasks. A reviewer subagent can also check completeness, spec alignment, and buildability.

Plans assume a spec already exists, so they do not replace brainstorming or requirements gathering. They also require discipline to keep steps concrete; vague steps without code blocks cause implementers to get stuck.