writing-plans

Define the file structure first, then break work into tasks where each task ends with an independently testable deliverable. Each step within a task should be a 2-5 minute action: write a failing test, run it, implement minimal code, verify it passes, then commit.

A task is the smallest unit that carries its own test cycle and deserves a fresh reviewer's attention. Fold setup and scaffolding into the task that needs them, and only split where a reviewer might reject one task while approving its neighbor.

Yes. Plans are saved to docs/superpowers/plans/ and support two execution modes: subagent-driven development with per-task review, or inline execution with batched checkpoints. The plan header declares the required execution sub-skill.

Placeholders like "add error handling" or "TODO" force the executing engineer to make undocumented design decisions, causing inconsistency and stalls. Every step must contain the actual code, test, or command so the plan is executable without improvisation.

Split when the spec covers multiple independent subsystems. Each plan should independently produce working, testable software, so one plan per subsystem keeps scope reviewable and deliverables coherent.