Subagent-Driven Development

What it does

This Superpowers workflow separates coordination from implementation. A controller reads the plan and specification, records a preflight conflict scan, and hands each task to a fresh implementer through a file-based brief. Implementers report their evidence before a task reviewer assesses both specification compliance and code quality. A final whole-branch review checks interactions once the tasks finish. The reviewed version has a bounded fix loop, explicit rulings and persistent reports; reducing it to “spawn agents and review later” misses its recovery and escalation mechanisms. It executes implementation tasks sequentially to avoid conflicting writers.

When to use it

• Carry out a multi-task migration with a reachable specification and explicit acceptance criteria.
• Resume a long implementation after context loss using a ledger tied to real commits.
• Keep task implementation and independent review separate on a change with integration risk.

Step-by-step workflow

1. Verify the isolated workspace, identify the governing specification and plan, and create or resume the plan-specific progress ledger.
2. Record preflight conflicts and prepare one exact task brief with constraints and artifact/report paths.
3. Dispatch the implementer, preserve its status and verify that the report includes tests and actual changes.
4. Review the task’s complete commit range for spec compliance and quality; follow the bounded fix-and-re-review process for material findings.
5. Run the broad final review, surface parked findings and rulings, and use the normal branch-finishing process before cleanup.

Example request

Use subagent-driven-development for the approved cache migration plan. The specification is specs/cache.md. Keep a ledger of task boundaries, commits, verification and rulings. Give each implementer only its task brief and required interfaces. Review the complete task range rather than HEAD~1. Do not merge, publish or discard unresolved load-bearing concerns as if they were a clean completion.

Worked example

A task spans three commits, but the reviewer only sees the final commit if given HEAD~1. The workflow instead records the base before implementation and packages the entire range. If review finds a concurrency defect, a fix round includes the correction and a scoped re-review. The reviewed source caps the per-task loop at five rounds, with fresh, more capable implementation in later rounds; unresolved findings require explicit rulings and appropriate routing. A ledger entry is needed for recovery, but does not itself prove the changed code works.

What you get

Implemented task commits, file-based reports, task and final review evidence, plus a recovery ledger with visible decisions.

How to evaluate the result

• Task briefs preserve the exact requirements and review ranges include all commits.
• Both spec and quality verdicts are present with evidence.
• Residual findings, costs of rulings and integration checks reach the final report.

What you need

An agreed plan, preferably a reachable specification, Git history, an isolated workspace and a host with implementer/reviewer tools. Referenced templates and scripts are part of the source package.

Setup and activation

Read the Superpowers README for the selected client and retain the referenced templates and supporting files. This directory reviewed source only; it did not install or execute the skill. Before adopting it, scan the exact version, inspect requested tools and permissions, and test on disposable non-sensitive inputs. A compatible instruction format does not establish identical host capabilities.

Limits and considerations

More expensive than direct execution for a trivial change. A reviewer’s approval is not a security or correctness guarantee. Parked concerns and provisional rulings must remain visible; the workflow does not authorize merges or publication outside the agreed scope.

Related workflows

• Use writing-plans to prepare executable tasks before starting this workflow.
• Use finishing-a-development-branch to choose the authorized delivery and cleanup path.

License and reuse

MIT at repository level. Preserve copyright and license notices; check companion files and external dependencies for their own terms.

Further reading

• Publisher setup and compatibility instructions
• Reviewed source at immutable commit