Subagent-Driven Development (obra/superpowers)

tl;dr: the same-session execution path from obra/superpowers. One fresh implementer subagent per plan task, then a per-task review (spec compliance and code quality), then a broad whole-branch review at the end. Ledger-driven progress survives context compaction. Use it when you have a plan and you want the agent to walk it without checking in between tasks.

What it actually does

The SKILL.md (fetched 2026-09-10) defines a controller loop over a plan file:

1. Setup. Open or create a per-plan workspace at <repo>/.superpowers/sdd/<plan-basename>/. Inside it: a progress.md ledger whose first line names the plan file. Read the plan once, note global constraints, make one todo per task.
2. Per-task loop. Dispatch a fresh implementer subagent with a brief file (the full task text) plus a report file path. Implementer implements, tests, commits, self-reviews, writes the report, returns short status (DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED). Then the controller generates a diff file and dispatches a task reviewer. Reviewer returns spec ✅/❌ + Critical/Important/Minor findings.
3. Fix loop, max 5 rounds. Rounds 1–3 resume the original implementer. Rounds 4–5 dispatch a fresh implementer on a more capable model. After each round: a scoped re-review. At round 5: the controller adjudicates open findings itself; load-bearing ones become ledger Ruling: entries.
4. Final whole-branch review on the most capable available model, one fix dispatch, one re-review, adjudicate residuals.
5. Finish. Surface every Ruling: to the human partner. Delete the workspace. Hand off to finishing-a-development-branch.

Core rules the skill is dogmatic about:

• Subagents do not inherit session context. Each dispatch carries exactly the brief, the interfaces, the global constraints, and the report path. Nothing else.
• Ledger > todos. Conversation memory dies at compaction. Controllers without a ledger have re-dispatched entire completed task sequences. The ledger is the recovery map.
• Never dispatch parallel implementers on the same plan. Conflicts. Sequential.
• Never fix findings in the controller session. Resume the implementer. Controller fixes skip review.
• Four things stop the loop, only those: an irreversible operation, a security-sensitive action, a side effect outside the worktree (merge / shared-branch push / publish), or a plan so broken every path forward is a guess.

When to use, when not

The SKILL.md ships a decision diagram:

The executing-plans distinction is the most-missed one: that skill runs in a separate session, this one runs here, with the same controller coordinating every dispatch.

Model selection

The skill is explicit about cost discipline:

• Mechanical tasks (isolated functions, clear spec, 1–2 files) → cheapest tier.
• Integration / judgment tasks (multi-file, pattern matching, debug) → standard.
• Architecture / design and the final whole-branch review → most capable available.
• Fix rounds 4–5 → at least one tier above the original implementer.
• Always specify model on dispatch. Omitted model inherits the session default — often the most expensive — which silently defeats this section.
• Turn count beats token price. Cheapest models on multi-step work routinely take 2–3× the turns, costing more overall. Floor at mid-tier for prose-spec implementers and reviewers.

When it fires

Frontmatter description: “Use when executing implementation plans with independent tasks in the current session.” Hosts that load skill metadata (Claude Code, Cursor via plugins) pick this up automatically. The same using-superpowers bootstrap that injects brainstorming triggers this on plan-execution patterns.

Install

# Claude Code — official Anthropic marketplace
/plugin install superpowers@claude-plugins-official

# Claude Code — Superpowers marketplace (alternative)
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

The README documents ten+ other install surfaces (Antigravity, Codex App/CLI, Cursor, Devin CLI, Factory Droid, Gemini CLI, GitHub Copilot CLI, Grok Build CLI, Kimi Code, OpenCode, Pi, Hermes Agent). None of them is npx skills add obra/superpowers — that is the skills.sh command for a different ecosystem. Do not invent that name.

To load just this SKILL.md without the rest of the methodology, clone the repo and copy skills/subagent-driven-development/SKILL.md into the host’s skills directory.

Gotchas

• Subagent context is not free. Every artifact you paste into a dispatch prompt stays in your controller context for the rest of the session. One real session’s dispatch hit 42k chars of which 99% was pasted history. Hand artifacts over as files; keep dispatch prompts to task + interfaces + global constraints.
• Brief file is the source of truth. The skill ships scripts/task-brief PLAN_FILE N to extract the task text to a uniquely named file. The implementer reads that, never the whole plan.
• Review package before reviewer. Run scripts/review-package PLAN_FILE BASE HEAD and pass the printed path to the reviewer. HEAD~1 silently drops all but the last commit of a multi-commit task — record BASE before dispatching the implementer.
• Worker-spawned reviewers are a defect, not rigor. Implementers never dispatch subagents, including reviewers. The controller dispatches both. Every reviewer a worker spawns is a duplicate seat.
• Adjudicate only at the breaker cap. Rounds 1–4 you cannot rule findings closed — let the implementer fix. At round 5 you adjudicate, and every ruling is a ledger Ruling: line. Silent discards are forbidden.
• Minor findings never enter the loop. Roll them to the ledger so the final review sees them; otherwise they are a silent discard.
• Plan-mandated findings need a ruling, not a dismissal. If the plan text says X and the reviewer flags Y, the spec is the binding authority, the plan argues from it, and the ruling goes in the ledger.
• Cursor is partial, not full. Cursor’s subagent support is real but the metadata model is thinner than Claude Code’s; triggers may not fire as reliably.
• sandbox_test is untested — we read the file, we did not run a plan-execution drill in the sandbox. Per config/skill-safety.md, this stays untested until a human runs the eval-vs-prompt harness.

Related

• Executing Plans (obra/superpowers) — sibling skill, runs the same plans but in a separate session with human checkpoints
• Dispatching Parallel Agents (obra/superpowers) — when failures are independent you batch in one response instead of serial per-task
• Requesting Code Review (obra/superpowers) — the per-task and final reviews both go through this skill’s reviewer template
• Finishing a Development Branch (obra/superpowers) — the skill this one hands off to when the loop is clean