Jesse Vincent (obra) / subagent-driven-development
How do you get a whole plan built without checking in after every task?
Give each task a fresh implementer and a reviewer, run the tasks one after another, and stop for only four reasons.
What to remember
- Tasks run in sequence. The skill rules out parallel implementation subagents because they conflict.
- Every task needs both verdicts, spec compliance and code quality, and the implementer's self-review never stands in for them.
- Progress is kept in a ledger file in a git-ignored workspace, because conversation memory does not survive compaction.
- Each role gets an explicitly chosen model: a fast, cheap one for mechanical tasks and the most capable available for the final whole-branch review.
01What it changes in practice
Working through a long plan in one context means every task carries the clutter of the tasks before it. Here the controlling session hands each task to a new implementer along with a brief extracted from the plan, then gives the resulting diff to a reviewer as a file, which leaves the controller's own context free for coordination.
The run also does not wait on you. Conflicts, ambiguities and plan defects are settled on the spot, with the spec as the binding authority, and each ruling goes into the ledger with what it costs if wrong. When the work is done the rulings are collected into the last message, so you can find and undo the ones you disagree with.
02Where it disappoints
It is not cheap. By its own account it costs a fresh context per task and per review, where inline execution costs one context and one final reviewer, and a task that keeps failing review can take up to five fix rounds before the open findings are parked.
It also depends on the plan being good. Tightly coupled tasks are outside its scope, and rulings made without a reachable spec count as provisional, so a vague plan turns into a fast series of decisions you will have to check afterwards.
Install and first run
- Install superpowers from obra/superpowers, published under MIT. The skill ships its SKILL.md with prompt templates for the implementer and the reviewers, seven reference files and three bash scripts.
- Have the plan written before you start, and work in an isolated worktree. The skill will not begin implementation on main or master without your explicit consent.
- Expect it to run to the end. It stops only for an irreversible or destructive operation, a security-sensitive action, a side effect outside the worktree such as a push or a publish, or a plan so broken that every way forward is a guess.
Questions people actually ask
- Does it run subagents in parallel?
- No. Implementers work one task at a time, and the skill forbids dispatching several implementation subagents at once because they conflict. Unrelated problems that can be worked on simultaneously are what dispatching-parallel-agents is for.
- How is it different from executing-plans?
- Both run the plan in the current session, share the same workspace and ledger, and never pause between tasks. executing-plans does every task in one context with a single reviewer at the end, while this skill uses a fresh subagent and a review for each task.
- What happens when a review finds problems?
- A fix loop. The same implementer is resumed for the first three rounds, a fresh one on a more capable model takes rounds four and five, and anything still open is parked with a ruling in the ledger. Minor findings skip the loop and wait for the final review.
Sources
Machine readable versions of this page