Why Superpowers Insists on Subagent‑Driven Development

Why Superpowers Strongly Promotes Subagent‑Driven Development

Following the previous two articles, the next step feels natural: the earlier layers solved brainstorming (don’t start implementing too early) and writing‑plans (don’t enter implementation with a vague plan). The question now is why not let a single agent handle the whole process from start to finish.

Superpowers defines “execution” not as simply turning a finished plan into code, but as a series of explicit steps. The repository’s core execution skills are subagent‑driven‑development, executing‑plans, and dispatching‑parallel‑agents. Among them, the recommended path is subagent‑driven‑development (SDD).

What Problem It Solves

SDD addresses the issue that a single agent doing many things quickly amplifies errors. In AI coding this manifests as:

Bias accumulation: an early 10% misunderstanding can propagate unchecked.

Difficulty distinguishing “spec compliance” from “code looks good”.

Misplaced confidence: the amount of work done is taken as evidence of correctness.

SDD adds a series of “shock absorbers” to the execution phase to contain these risks.

Why It Insists on “One Task, One Fresh Sub‑Agent”

The skill explicitly states: each task uses a brand‑new sub‑agent , rather than a single implementation sub‑agent handling the whole plan. The reasoning is that context accumulation pollutes judgment, so a fresh sub‑agent works with the minimal necessary context:

What the current task must accomplish.

Its position in the overall design.

Which files to modify.

Which validations to run.

If a review fails, the sub‑agent must fix the issue and undergo re‑review; the main agent never edits the task directly.

Why Reviews Are Ordered Strictly

SDD requires two reviews in a fixed order:

Spec‑compliance review.

Code‑quality review.

The spec‑compliance review checks whether the implementation actually satisfies the specification (no missing requirements, no extra work, correct interpretation, and no false claims of completion). The code‑quality review then examines structure, error handling, file responsibilities, test quality, and maintenance risk. Reversing the order would let a clean‑looking code hide a fundamental spec mismatch, which Superpowers explicitly rejects.

Where executing‑plans Fits

executing‑plans

is a fallback when sub‑agents cannot be used (e.g., unsuitable environment, tightly coupled tasks, or a desire for sequential execution). Its workflow is:

Read the full plan.

Perform a critical review.

Execute step‑by‑step according to the plan.

Wrap up after all steps are done.

Compared with SDD, it lacks per‑task isolation, double‑layer review, and relies more on the single agent’s discipline.

What dispatching‑parallel‑agents Solves

This skill targets independent problems that can be investigated in parallel, such as multiple failing test files, bugs in separate subsystems, or issues without shared state. Its process is:

Domain partitioning.

Assign one sub‑agent per domain.

Parallel investigation.

Integrate results and perform a final verification.

It complements SDD but does not replace it; SDD focuses on serial task execution with strict quality gates, while parallel agents aim at efficiency when tasks are truly independent.

Common Misunderstandings

1. It’s about “more agents = fancier”

Agents are merely a means to isolate context and responsibility, not an end goal.

2. Reviews are a courtesy, not a gate

In this system, a failed spec review or a critical code‑quality issue blocks progress entirely.

3. Letting a sub‑agent read the plan saves work

Superpowers deliberately prevents sub‑agents from reading the plan themselves; the coordinator parses the plan and hands the complete task text to the sub‑agent, eliminating ambiguous interpretation and keeping control centralized.

Core Engineering Judgment

Superpowers treats execution as a controlled process, enforcing:

Controlled context.

Controlled task boundaries.

Controlled requirement interpretation.

Controlled review order.

Controlled fix timing.

This contrasts with the “let the model figure everything out” mindset; the system deliberately avoids relying on a single agent’s continuous vigilance.

One‑Sentence Summary of SDD

It does not let many agents write code together; it breaks the implementation phase into isolated, reviewable, locally closed‑loop engineering steps.

What Comes Next

The next article will examine why Superpowers makes TDD, systematic debugging, and verification hard constraints, diving deeper into the repository’s most stringent skills.