Subagent-Driven Development
Dispatches a fresh implementer subagent per task in the same session, with two-stage review and a progress ledger that survives context compaction
Provides a concrete multi-agent execution and review workflow for an existing plan with mostly independent tasks in the current session. The implementer, task-review, fix loop, and final branch review offer a meaningful quality advantage, and boundaries are stated for tightly coupled work, parallel sessions, and missing plans. No quantitative success-rate or scale evidence is provided.
Task briefs, report files, a progress ledger, explicit status handling, commit-range review packages, and re-review after fixes provide useful recovery and reproducibility structure. Reliability depends on the harness supporting subagent dispatch, file operations, Git, tests, and several shared skills; this file does not define compatibility, retry limits, or fallbacks when tools are unavailable. There is no skill-specific execution test evidence.
The skill requires explicit consent before implementation on the main branch and directs use of isolated worktrees, review loops, and branch-finishing procedures, which reduce the risk of direct destructive changes. Implementers modify files, run tests, and commit, while continuous execution avoids human confirmation between tasks; this leaves limited immediate containment for mistaken agent actions. Permission boundaries, sensitive-data handling, task-level approval points, and concrete rollback steps are not specified.
The process has strong traceability mechanisms on paper, including base and head commits, diff packages, test reports, and ledger entries. However, no behavior tests, execution results, independent assessment, or cross-environment validation for this skill are supplied. Passing tests in the example are illustrative rather than evidence verified in this review, and the workflow largely relies on self-reported test results without a clear independent verification mechanism.
Trigger conditions, applicability guidance, diagrams, status definitions, model-selection advice, file-handoff rules, and prompt templates are fairly complete for an operator familiar with the framework. New users still need to understand plan files, tool calls, Git worktrees, shared skills, and script locations. Inputs and outputs, operating cost, platform compatibility, missing-tool troubleshooting, and safe exit procedures are only partially documented.
Repository context supplies an MIT license and version 6.1.1, but the selected skill has no version, changelog, maintainer responsibility, or skill-specific update path. It references several other skills, templates, and scripts that may drift over time; no compatibility matrix or response process is provided. The publisher is not verified by the curated enterprise registry, so no additional governance credit is warranted.
- Continuous execution can reduce user intervention during long tasks; add human approval gates and stop conditions for high-impact code, production configuration, or sensitive data.
- Before adoption, confirm that the referenced shared skills, scripts, subagent tools, and Git worktree capabilities exist and are version-compatible.
- Do not treat implementer reports or example passing tests as independent verification; check the actual commands, coverage, output, and committed diff.
- The workflow requires commits but does not give detailed rollback operations; establish recovery procedures for branches, worktrees, commits, and uncommitted changes before execution.
What it does & when to use it
The skill that actually does the coding in the Superpowers workflow: dispatch a brand-new implementer subagent per task (no inherited session history), generate a diff package once it's done, dispatch a task-reviewer subagent for a two-stage check (spec compliance + code quality), only mark the task complete once it passes, and run one final whole-branch review after every task is done. It has a dedicated progress-ledger mechanism for long sessions that get compacted — recovery relies on git log and the ledger file, not memory — which makes this the longest (418 lines) and most rule-dense skill in the set.
Reads the plan, notes global constraints, creates todos. Per task: dispatch an implementer subagent (via the implementer-prompt.md template) → answer any questions it raises → it implements, tests, commits, and self-reviews → generate a review package (the review-package script) → dispatch a task-reviewer subagent (via task-reviewer-prompt.md) → if it fails, dispatch a fix subagent and re-review → once it passes, append one line to the ledger ("Task N: complete"). After all tasks finish, dispatches a final whole-branch review, then hands off to finishing-a-development-branch. Also includes a model-tiering strategy (cheap model for mechanical work, mid-tier for judgment calls, most capable for architecture), detailed rules for constructing reviewer prompts (never pre-judge findings, never ask a reviewer to re-run tests the implementer already ran, copy constraints verbatim from the plan), and concrete guidance for handing artifacts around as files instead of pasting them into context.
- You have a plan from writing-plans with mostly-independent tasks and want to iterate quickly in the current session rather than switching sessions
- A long session gets compacted mid-plan and needs to recover "where were we" from the progress ledger and git log instead of guessing from memory
- Automatically pick a subagent's model tier based on task complexity — cheap model for mechanical changes, most capable for architectural judgment — to control cost
Pros & cons
- Two-stage review (spec compliance + code quality) plus a final whole-branch review is far more rigorous than most "write it and call it done" workflows
- The progress-ledger mechanism addresses a real long-session pain point — forgetting progress and re-executing completed tasks after context compaction — a genuinely practical engineering consideration
- Gives a very concrete anti-pattern list for constructing reviewer prompts (no pre-judging findings, no asking a reviewer to re-run the implementer's tests, constraints must be copied verbatim, not paraphrased), reducing how much a reviewer subagent can be steered toward a predetermined conclusion
- Only reliably self-enforcing on harnesses that actually read and follow SKILL.md instructions (Claude Code, Codex CLI, etc.) — in a plain chat interface it's just a document a human has to apply by hand.
- At 418 lines, it's the longest of the set — dense enough that reading and internalizing it end to end takes real effort
- The full loop involves many subagent dispatches (at least 2 per task, more when issues surface), noticeably higher in token and time cost than writing the code directly — best suited when quality matters more than speed
How to install
Installed as part of the obra/superpowers plugin — individual skills can't be installed standalone:
- Claude Code: official marketplace
/plugin install superpowers@claude-plugins-official; or register the community marketplace with/plugin marketplace add obra/superpowers-marketplacethen/plugin install superpowers@superpowers-marketplace - Also supports Antigravity, Codex App/CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, and Pi — see the repo README for the exact command per harness
Once installed, this skill activates alongside the other 13 Superpowers skills, auto-triggered by using-superpowers based on context — there's no separate invocation step.
How to use
Use when you have a multi-task implementation plan with relatively independent tasks and want fast iteration in the current session; it's an either/or choice with executing-plans — not meant for use on the same plan simultaneously.
Compared to similar skills
Compared to executing-plans, this is the heavyweight version: more thorough subagent isolation, stricter review (two-stage plus final review), and a ledger that prevents lost progress — at the cost of more subagent dispatches and higher token spend. executing-plans is the lighter option for environments without subagent support or when lower overhead matters more.