Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →guanyang/subagent-driven-development
Use when executing implementation plans with independent tasks in the current session
Passed 13 of 20 test cases with the skill, and 7 of 20 without it.
and 8 more in the full report
7 fixed8 passed either way8 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
During the task review for Task 4 in `docs/plans/payment-gateway.md`, the reviewer approved spec compliance and code quality, but flagged two minor formatting inconsistency issues (Minor severity). Should we launch a fix subagent loop to resolve these minor issues right now, or how should minor findings be handled?
| Checked | Without skill | With skill |
|---|---|---|
| Logs the minor findings in the progress ledger as deferred minor items without entering a fix loop. | Missed | Passed |
| Defers resolution of minor findings to the final whole-branch review phase. | Missed | Passed |
The instructions your model reads when the skill loads.
Execute plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.
Why subagents: You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
Core principle: Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration
Narration: between tool calls, narrate at most one short line — the ledger and the tool results carry the record.
Continuous execution: Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are the four named below, or all tasks complete. "Should I continue?" prompts and progress summaries waste their time — they asked you to execute the plan, so execute it.
Rulings, not stalls. A running plan does not wait on a human. Conflicts,
ambiguities, plan defects, a cap you would have asked to exceed — decide
them. The spec is the binding authority, the plan is its argument, and your
judgment settles what neither answers. Record every decision in the ledger as
Ruling: <what you decided> — <why> — <what it costs if wrong>, and keep
going. A wrong ruling costs rework your human partner can see and undo; a
session parked on a question costs their whole day and buys nothing.
Four things stop you, and only these: an irreversible or destructive operation; a security-sensitive action; a side effect outside this worktree that norms say you ask about first (a merge, a push to a shared branch, a publish); and a plan so broken that every path forward is a guess. For those, stop and ask.
digraph when_to_use {
"Have implementation plan?" [shape=diamond];
"Tasks mostly independent?" [shape=diamond];
"Partner chose inline, or no subagent tool?" [shape=diamond];
"subagent-driven-development" [shape=box];
"executing-plans" [shape=box];
"Manual execution or brainstorm first" [shape=box];
"Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
"Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
test cases passed, vs 7 / 20 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.