139 lines
4.7 KiB
Markdown
139 lines
4.7 KiB
Markdown
---
|
|
name: subagent-driven-development
|
|
description: Use when executing implementation plans with independent tasks in the current session
|
|
---
|
|
|
|
# Subagent-Driven Development
|
|
|
|
Execute plan by dispatching fresh subagent per task, with two-stage review after each: spec compliance review first, then code quality review.
|
|
|
|
**Why subagents:** You delegate tasks to specialized agents with isolated context. They should never inherit your session's context or history — you construct exactly what they need. This preserves your own context for coordination work.
|
|
|
|
**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration
|
|
|
|
## When to Use
|
|
|
|
Use when you have an implementation plan (from writing-plans skill) with multiple independent tasks.
|
|
|
|
## The Process
|
|
|
|
1. **Read plan file** — `docs/superpowers/plans/[name].md`
|
|
2. **Extract all tasks** with full text and context
|
|
3. **Create TodoWrite** with all tasks
|
|
4. **For each task:**
|
|
a. Dispatch implementer subagent with full task text + context
|
|
b. If implementer asks questions → answer, provide context, re-dispatch
|
|
c. Implementer implements, tests, commits, self-reviews
|
|
d. Dispatch spec reviewer subagent → confirms code matches spec
|
|
e. If spec issues → implementer fixes, re-review
|
|
f. Dispatch code quality reviewer subagent → reviews quality
|
|
g. If quality issues → implementer fixes, re-review
|
|
h. Mark task complete in TodoWrite
|
|
5. **After all tasks:** Dispatch final code reviewer for entire implementation
|
|
6. **Invoke finishing-a-development-branch** to complete
|
|
|
|
## Implementer Subagent Prompt Template
|
|
|
|
When dispatching an implementer subagent, provide:
|
|
|
|
```
|
|
You are implementing Task [N] from the implementation plan.
|
|
|
|
## Task
|
|
[Full task text from plan]
|
|
|
|
## Context
|
|
- Project: Construction Delivery Control (React + Supabase)
|
|
- Stack: React 18, React Router 7, Tailwind CSS, Framer Motion, Vitest
|
|
- Test convention: TDD — write failing test first, minimal code to pass
|
|
- File conventions: Components by domain in src/components/, services in src/services/
|
|
|
|
## Files to modify
|
|
[List exact file paths]
|
|
|
|
## Requirements
|
|
- Follow TDD: write failing test first, then minimal code
|
|
- Commit after each passing test
|
|
- Self-review your work before reporting complete
|
|
- Do NOT modify files outside this task's scope
|
|
|
|
Report status when done: DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, or BLOCKED.
|
|
```
|
|
|
|
## Spec Reviewer Subagent Prompt Template
|
|
|
|
```
|
|
Review whether the implementation matches the spec for Task [N].
|
|
|
|
## Task Spec
|
|
[Full task text from plan]
|
|
|
|
## What was implemented
|
|
[Summary from implementer]
|
|
|
|
## Files changed
|
|
[git diff or file list]
|
|
|
|
Check:
|
|
1. Does the code implement all requirements from the task?
|
|
2. Does the code add anything NOT requested?
|
|
3. Are there any missing edge cases or error handling from the spec?
|
|
|
|
Report: ✅ Spec compliant, or ❌ with specific issues.
|
|
```
|
|
|
|
## Code Quality Reviewer Subagent Prompt Template
|
|
|
|
```
|
|
Review the code quality for Task [N].
|
|
|
|
## What was implemented
|
|
[Summary]
|
|
|
|
## Files changed
|
|
[git diff between BASE_SHA and HEAD_SHA]
|
|
|
|
Review for:
|
|
1. Code clarity and readability
|
|
2. Proper error handling
|
|
3. Consistent naming and style (follow existing project conventions)
|
|
4. Test quality and coverage
|
|
5. No magic numbers or hardcoded values
|
|
6. Proper separation of concerns
|
|
|
|
Report strengths, issues (with severity), and approval status.
|
|
```
|
|
|
|
## Handling Implementer Status
|
|
|
|
- **DONE:** Proceed to spec compliance review
|
|
- **DONE_WITH_CONCERNS:** Read concerns before proceeding. Address if about correctness/scope.
|
|
- **NEEDS_CONTEXT:** Provide missing context and re-dispatch
|
|
- **BLOCKED:** Assess blocker — context issue? Provide context. Reasoning issue? Use more capable model. Plan issue? Escalate to human
|
|
|
|
## Model Selection
|
|
|
|
- **Mechanical tasks** (1-2 files, clear spec) → use fast/cheap model
|
|
- **Integration tasks** (multi-file, coordination) → use standard model
|
|
- **Architecture/review** → use most capable available model
|
|
|
|
## Red Flags
|
|
|
|
**Never:**
|
|
- Start implementation on main/master branch
|
|
- Skip reviews (spec compliance OR code quality)
|
|
- Proceed with unfixed issues
|
|
- Dispatch multiple implementation subagents in parallel (conflicts)
|
|
- Make subagent read plan file (provide full text instead)
|
|
- Ignore subagent questions
|
|
- Accept "close enough" on spec compliance
|
|
- Start code quality review before spec compliance is ✅
|
|
- Move to next task while either review has open issues
|
|
|
|
## Integration
|
|
|
|
**Required workflow skills:**
|
|
- **superpowers:using-git-worktrees** — REQUIRED: Set up isolated workspace before starting
|
|
- **superpowers:writing-plans** — Creates the plan this skill executes
|
|
- **superpowers:finishing-a-development-branch** — Complete development after all tasks
|