Use when executing implementation plans with independent tasks in the current session. Dispatches a fresh subagent per task with two-stage review (spec compliance then code quality) after each. Serial execution for coupled tasks or when agent teams are unavailable.
From casaflownpx claudepluginhub casaperks/casaflow --plugin casaflowThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
PURPOSE: Execute an implementation plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance first, then code quality. Fresh context per task prevents context pollution and keeps each implementer focused.
Core principle: Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
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.
flowchart TD
A{Have implementation plan?} -->|yes| B{Tasks mostly independent?}
A -->|no| C[plan first]
B -->|yes| D{3+ tasks touching<br/>different files?}
B -->|no, tightly coupled| E[sdd]
D -->|yes| F{Agent teams enabled?}
D -->|no| E
F -->|yes| G[team-dev]
F -->|no| E
style E fill:#e8f5e9
Use sdd when:
Use team-dev instead when:
flowchart TD
read_plan[1. Read plan<br/>Extract all tasks] --> dispatch
subgraph per_task [Per Task - repeat for each]
dispatch[Dispatch implementer<br/>subagent with full task] --> questions{Implementer asks<br/>questions?}
questions -->|yes| answer[Answer questions<br/>provide context] --> dispatch
questions -->|no| implement[Implementer: implements,<br/>tests, commits, self-reviews]
implement --> spec_review[Dispatch spec<br/>reviewer subagent]
spec_review --> spec_pass{Spec compliant?}
spec_pass -->|no| spec_fix[Implementer<br/>fixes spec gaps] -.->|re-review| spec_review
spec_pass -->|yes| quality_review[Dispatch code quality<br/>reviewer - review fast-pass]
quality_review --> quality_pass{Quality passes?}
quality_pass -->|no| quality_fix[Implementer<br/>fixes quality issues] -.->|re-review| quality_review
quality_pass -->|yes| task_done[Mark task complete]
end
task_done --> more{More tasks?}
more -->|yes| dispatch
more -->|no| final_review[Final review of<br/>entire implementation]
final_review --> finish[Invoke finish]
style finish fill:#e8f5e9
Read the plan file once. Extract ALL tasks with their full text, noting:
For each task in order:
Spawn a fresh subagent with:
tdd for TDD disciplineModel selection guidance:
| Task Complexity | Signals | Recommended Model |
|---|---|---|
| Mechanical | Isolated functions, clear specs, 1-2 files, well-defined inputs/outputs | Fast/cheap model (haiku-class) |
| Integration | Multi-file coordination, pattern matching, debugging, API boundaries | Standard model (sonnet-class) |
| Architecture | Design judgment, broad codebase understanding, complex trade-offs | Most capable model (opus-class) |
Most implementation tasks are mechanical when the plan is well-specified. Default to the cheapest model that can handle the task. Escalate only when needed.
Implementer subagents report one of four statuses:
DONE: Proceed to spec compliance review.
DONE_WITH_CONCERNS: The implementer completed the work but flagged doubts. Read the concerns before proceeding. If the concerns are about correctness or scope, address them before review. If they are observations (e.g., "this file is getting large"), note them and proceed to review.
NEEDS_CONTEXT: The implementer needs information that was not provided. Provide the missing context and re-dispatch.
BLOCKED: The implementer cannot complete the task. Assess the blocker:
Never ignore an escalation or force the same model to retry without changes. If the implementer said it is stuck, something needs to change.
After the implementer reports DONE, dispatch a spec reviewer subagent:
If spec reviewer finds issues:
Spec compliance must pass before code quality review begins. Never reverse this order.
After spec compliance passes, dispatch the code quality review:
review skill at fast-pass tierIf quality review finds issues:
After both reviews pass, mark the task as complete and proceed to the next task.
After all tasks are complete, dispatch a final review of the entire implementation:
review at all tier for the full specialist swarmAfter the final review passes, invoke finish to present completion options (merge, PR, keep, discard).
Spec compliance FIRST -> Code quality SECOND
Why this order:
Every implementer subagent needs:
You are the controller. Your job is:
finish when all tasks passYou do NOT implement tasks yourself. You coordinate.
Never:
team-dev)If subagent asks questions:
If reviewer finds issues:
If subagent fails the task:
Controller: I'm using Subagent-Driven Development to execute this plan.
[Read plan file: docs/plans/2026-03-28-feature-plan.md]
[Extract all 5 tasks with full text and context]
Task 1: Data model
[Dispatch implementer subagent (haiku) with task text + context]
Implementer: "Before I begin -- should the ID field be UUID or auto-increment?"
Controller: "UUID, matching existing entity patterns in src/entities/"
Implementer: "Got it. Implementing now..."
[Later]
Implementer:
- Created entity with UUID
- Added 4 tests, all passing
- Self-review: clean
- Committed: "feat(data): add Widget entity with validation"
[Dispatch spec reviewer]
Spec reviewer: PASS -- all requirements met, nothing extra
[Dispatch quality review via review fast-pass]
Quality reviewer: PASS -- clean, well-structured
[Mark Task 1 complete]
Task 2: Service layer
[Dispatch implementer subagent (haiku) with task text + context from Task 1]
Implementer: [No questions, proceeds]
Implementer:
- Implemented CRUD service
- 6 tests passing
- Self-review: all good
- Committed
[Dispatch spec reviewer]
Spec reviewer: FAIL
- Missing: pagination support (spec says "paginated list endpoint")
- Extra: added soft-delete (not requested)
[Send findings to implementer]
Implementer: Removed soft-delete, added pagination. Committed fix.
[Re-dispatch spec reviewer]
Spec reviewer: PASS
[Dispatch quality review]
Quality reviewer: Minor -- magic number for page size. Extract constant.
[Send finding to implementer]
Implementer: Extracted PAGE_SIZE constant. Committed.
[Re-dispatch quality review]
Quality reviewer: PASS
[Mark Task 2 complete]
... (Tasks 3-5) ...
[All tasks complete]
[Dispatch final review of full implementation]
Final reviewer: All requirements met, cross-task integration clean.
[Invoke finish]
Called by:
plan (execution handoff) -- when user chooses sequential executionkickoff during the EXECUTE stageTerminal state:
finish after all tasks pass final reviewImplementer subagents use:
tdd -- TDD discipline for each taskReview uses:
review -- swarm review at fast-pass tier per task, all tier for final reviewRelated skills:
plan -- creates the plan this skill executesteam-dev -- parallel alternative for 3+ independent tasksverify -- verification discipline before claiming task completionfinish -- handles branch completion after all tasks passAlternative:
team-dev -- use for parallel execution when tasks are independent and agent teams are enabled| Aspect | Manual | Subagent-Driven |
|---|---|---|
| Context management | Accumulates, degrades | Fresh per task |
| Review discipline | Easy to skip | Enforced two-stage gate |
| Consistency | Varies with fatigue | Uniform quality |
| Progress tracking | Ad-hoc | Systematic task completion |
| Error isolation | Hard to pinpoint | Per-task review catches issues early |
| Cost vs. Quality | Low cost, variable quality | Higher cost, consistent quality |