domains / software-engineering / subagent-plan-execution / subagent-driven-development

subagent-driven-development

Skill card

combined

The copies overlap on the core loop (fresh implementer subagent per task, spec compliance review, code quality review, final whole-branch review, then finishing-a-development-branch), but they disagree on the review architecture and on operational constraints. obra/superpowers uses a single task reviewer that checks spec and quality together, adds a ledger, a 5-round fix cap with model escalation, adjudication of load-bearing findings, and explicit stop conditions. The other three copies use two separate reviewer subagents (spec then quality) and a simpler TodoWrite-based flow. Crowning one would hide a real alternative review strategy and the extra governance steps.

Repositories

RepositoryPath
obra/superpowersskills/subagent-driven-development/SKILL.md
foryourhealth111-pixel/Vibe-Skillsbundled/skills/subagent-driven-development/SKILL.md
sickn33/agentic-awesome-skillsplugins/agentic-awesome-skills-claude/skills/subagent-driven-development/SKILL.md
LeoYeAI/openclaw-master-skillsskills/subagent-driven-development/SKILL.md

Other copies

RoleRepositoryPath
peerobra/superpowersskills/subagent-driven-development/SKILL.md
peerforyourhealth111-pixel/Vibe-Skillsbundled/skills/subagent-driven-development/SKILL.md
peersickn33/agentic-awesome-skillsplugins/agentic-awesome-skills-claude/skills/subagent-driven-development/SKILL.md
peerLeoYeAI/openclaw-master-skillsskills/subagent-driven-development/SKILL.md
inferiorFreedomIntelligence/OpenClaw-Medical-Skillsskills/subagent-driven-development/SKILL.md
adaptersickn33/agentic-awesome-skillsplugins/agentic-awesome-skills/skills/subagent-driven-development/SKILL.md
adaptersickn33/agentic-awesome-skillsskills/subagent-driven-development/SKILL.md

Combined skill

# Subagent-Driven Development

Execute an implementation plan by dispatching a fresh implementer subagent per task, reviewing each task, and running a final whole-branch review.

## When to Use
- You have an implementation plan with mostly independent tasks.
- Execution stays in the current session.
- If tasks are tightly coupled, use manual execution or brainstorm first.
- If the partner chose inline execution or no subagent tool is available, use executing-plans.

## Core Principle
Fresh subagent per task + task review (spec compliance + code quality) + broad final review = high quality, fast iteration.

## Process
1. Setup: create a worktree, check the ledger, read the plan, and run a pre-flight review.
2. For each task:
   a. Dispatch an implementer subagent using ./implementer-prompt.md.
   b. If the implementer asks questions, answer them and provide context.
   c. The implementer implements, tests, commits, and self-reviews.
   d. Review the task:
      - Option A (single reviewer): dispatch a task reviewer using ./task-reviewer-prompt.md to check both spec compliance and code quality.
      - Option B (two-stage): dispatch a spec reviewer using ./spec-reviewer-prompt.md, then a code quality reviewer using ./code-quality-reviewer-prompt.md.
   e. If findings are returned, fix them and re-review. In the obra/superpowers variant, cap fix rounds at 5; for rounds 4-5, use a fresh implementer with a more capable model.
   f. If a finding conflicts with the plan text, rule on the conflict and record the ruling in the ledger.
   g. Mark the task complete in the ledger or TodoWrite.
3. After all tasks: dispatch a final code reviewer for the entire implementation.
4. If final findings exist, run one fix dispatch and one scoped re-review; adjudicate residuals.
5. Use superpowers:finishing-a-development-branch.

## Continuous Execution
Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping.

## Stop Conditions
Stop and ask only for:
- 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).
- A plan so broken that every path forward is a guess.

## Rulings, Not Stalls
A running plan does not wait on a human. Conflicts, ambiguities, plan defects, and caps you would have asked to exceed are decided by you. 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.

## Prompt Templates
- ./implementer-prompt.md - Dispatch implementer subagent
- ./task-reviewer-prompt.md - Dispatch task reviewer (spec + quality) [Option A]
- ./spec-reviewer-prompt.md - Dispatch spec compliance reviewer [Option B]
- ./code-quality-reviewer-prompt.md - Dispatch code quality reviewer [Option B]
- ./re-review-prompt.md - Dispatch scoped re-review [Option A]

## Example Workflow
```
You: I'm using Subagent-Driven Development to execute this plan.

[Read plan file once: docs/plans/feature-plan.md]
[Extract all tasks with full text and context]
[Create ledger or TodoWrite with all tasks]

Task 1: Hook installation script

[Dispatch implementation subagent with full task text + context]

Implementer: "Before I begin - should the hook be installed at user or system level?"

You: "User level (~/.config/superpowers/hooks/)"

Implementer: "Got it. Implementing now..."
[Later] Implementer:
  - Implemented install-hook command
  - Added tests, 5/5 passing
  - Self-review: Found I missed --force flag, added it
  - Committed

[Dispatch task reviewer or spec + quality reviewers]
Reviewer: ✅ Spec compliant and code quality approved

[Mark task complete]

[Repeat for remaining tasks]

[Dispatch final code reviewer for entire implementation]
[Use superpowers:finishing-a-development-branch]
```