writing-plans

Start with a plan header covering goal, architecture, and tech stack, then map the file structure before defining tasks. Each task lists exact files to create or modify, interface signatures, and bite-sized TDD steps with complete code and commit commands.

If the spec spans multiple independent subsystems, split it into separate plans, one per subsystem, each producing working testable software. Within a plan, size tasks so each ends with an independently testable deliverable a reviewer could approve or reject on its own.

Steps are plan failures if they contain placeholders like TBD, 'add appropriate error handling', or 'write tests for the above' without actual code. Every step must show the exact code, the exact command to run, and the expected output.

Skip the full plan for trivial single-file changes or exploratory spikes where requirements are still unclear. The planning overhead pays off only for multi-step tasks where an implementer needs complete context to work independently.

Plans are saved to docs/superpowers/plans/ with a dated filename, then executed either by dispatching a fresh subagent per task with review between tasks, or inline in the same session with batched execution and checkpoints.