Superpowers Scales Work Through Delegation and Review

The tests and debugging practices in obra/superpowers produce evidence for an individual task. This chapter focuses on what happens when the work is large enough to divide: how subagent-driven development separates coordination from implementation, how review turns a task into two independent judgments, and how parallelism and model choice are constrained by task shape. The practical question is not how to add more agents. It is how to increase throughput without multiplying context mistakes, duplicated reviews, and unexamined confidence.

The controller is a context allocator

A coding agent working alone carries the whole conversation, the plan, the repository, the current edits, and the temptation to solve every adjacent problem. Superpowers' subagent-driven development model changes that arrangement. A controller coordinates the plan, while a fresh implementer handles one focused task in a deliberately limited context. The implementer does not inherit the controller's entire conversation history; the controller supplies the task's requirements and the interfaces it needs.

This is context isolation, not just delegation. A fresh context reduces the amount of unrelated reasoning an implementer must hold at once. It also makes the handoff inspectable. The task brief states the exact requirements, the report records what the implementer did and tested, and the review package carries the relevant diff. The controller can coordinate from those artifacts instead of pasting a growing history into every new request.

The separation assigns ownership. The plan owns the intended task contract. The implementer owns the code and tests for that task. The reviewer owns an independent assessment of the diff. The controller owns sequencing, unresolved questions, and the decision about whether a finding is fixed, deferred, or load-bearing. No role is asked to pretend it owns another role's evidence.

That division also limits recursive delegation. An implementer does not spawn a helper or a reviewer, and a reviewer does not modify the working tree. A worker-created reviewer would duplicate the controller's task-review gate and could inspect the same change with a different, uncoordinated scope. Superpowers treats the extra activity as a defect in the workflow, not as free assurance. More activity is useful only when it creates a distinct evidence surface.

The process begins with an isolated workspace, a plan read once, a plan-scoped progress ledger, and a pre-dispatch scan for contradictions. Before the first task, the controller checks relationships among tasks that share a file or interface and checks whether each task agrees with itself. This is a different kind of review from reviewing code: it asks whether the plan can be executed without forcing downstream workers to guess.