ct-subagent-driven-development

Read the plan once, create todos for all tasks, then dispatch a fresh implementer subagent per task with a task brief file. After each task, generate a review package and dispatch a task reviewer; finish with a whole-branch review.

Use subagent-driven development when tasks are mostly independent and you want to stay in the same session with continuous execution. Use the executing-plans approach when you prefer a separate parallel session with human checkpoints between tasks.

The ledger at .superpowers/sdd/progress.md records each completed task with its commit range. After context compaction or a resume, the controller trusts the ledger and git log over its own memory and skips tasks already marked complete.

Critical and Important findings go to a fix subagent that re-runs covering tests and appends results to the report file. The reviewer then re-reviews the updated diff, and the loop repeats until both spec compliance and quality are approved.

Always specify the model explicitly, since an omitted model inherits the session's most expensive one. Use a mid-tier model as the floor for implementers and reviewers, reserving the most capable model for architecture work and the final whole-branch review.

Avoid it when tasks are tightly coupled and cannot proceed independently, when no implementation plan exists yet, or when you cannot work on an isolated branch. Write the plan first and never start implementation on main without explicit consent.