Subagent-Driven Development
Execute plan by dispatching fresh subagent per task, with code review after each.
Core principle: Fresh subagent per task + review between tasks = high quality, fast iteration
Overview
vs. Executing Plans (parallel session):
- Same session (no context switch)
- Fresh subagent per task (no context pollution)
- Code review after each task (catch issues early)
- Faster iteration (no human-in-loop between tasks)
When to use:
- Staying in this session
- Tasks are mostly independent
- Want continuous progress with quality gates
When NOT to use:
- Need to review plan first (use ring:executing-plans)
- Tasks are tightly coupled (manual execution better)
- Plan needs revision (brainstorm first)
The Process
1. Load Plan
Read plan file, create TodoWrite with all tasks.
1.5 Handle Multi-Module Tasks (if applicable)
If plan has tasks with target: and working_directory: fields:
- Track current module context:
current_module = None current_directory = "." - Before dispatching task subagent, check for context switch:
IF task.target!= current_module AND current_module!= None: # Prompt user for confirmation AskUserQuestion: question: "Switching to {task.target} module at {task.working_directory}. Continue?" header: "Context" options: - label: "Continue" description: "Switch and execute task" - label: "Skip task" description: "Skip this task" - label: "Stop" description: "Stop execution" Handle response accordingly - Include working directory in subagent prompt:
Task(subagent_type=task.agent, model="opus", prompt="Working directory: {task.working_directory} FIRST: cd {task.working_directory} THEN: Check for PROJECT_RULES.md and follow if exists {original task prompt}")
Optimization: Reorder tasks to minimize context switches (if no dependencies between modules).
2. Execute Task with Subagent
Dispatch: Task tool with: Task N from [plan-file], working directory (if multi-module), instructions (implement, test with TDD, verify, commit, report back). Subagent reports summary.
3. Review Subagent's Work (Parallel Execution)
CRITICAL: Single message with 5 Task tool calls - all reviewers execute simultaneously.
| Reviewer | Context |
|---|---|
ring:code-reviewer | WHAT_WAS_IMPLEMENTED, PLAN, BASE_SHA, HEAD_SHA |
ring:business-logic-reviewer | Same context |
ring:security-reviewer | Same context |
ring:test-reviewer | Same context |
ring:nil-safety-reviewer | Same context |
Each returns: Strengths, Issues (Critical/High/Medium/Low/Cosmetic), Assessment (PASS/FAIL)
4. Aggregate and Handle Review Feedback
Aggregate all issues by severity across all 5 reviewers.
| Severity | Action |
|---|---|
| Critical/High/Medium | Dispatch fix subagent → Re-run all 5 reviewers → Repeat until clear |
| Low | Add # TODO(review): [issue] - reviewer, date, Severity: Low |
| Cosmetic | Add # FIXME(nitpick): [issue] - reviewer, date, Severity: Cosmetic |
Commit TODO/FIXME comments with fixes.
5. Mark Complete, Next Task
After all Critical/High/Medium issues resolved for current task:
- Mark task as completed in TodoWrite
- Commit all changes (including TODO/FIXME comments)
- Move to next task
- Repeat steps 2-5
6. Final Review (After All Tasks)
Same pattern as Step 3 but reviewing entire implementation (all tasks, full BASE_SHA→HEAD_SHA range). Aggregate, fix, re-run until all 5 PASS.
7. Complete Development
After final review passes:
- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
- REQUIRED SUB-SKILL: Use finishing-a-development-branch
- Follow that skill to verify tests, present options, execute choice
Example Workflow
Task 1: Implement → All 5 reviewers PASS → Mark complete.
Task 2: Implement → Review finds: Critical (hardcoded secret), High (missing password reset, missing input validation), Low (extract token logic) → Dispatch fix subagent → Re-run reviewers → All PASS → Add TODO for Low → Mark complete.
Final: All 5 reviewers PASS entire implementation → Done.
Why parallel: 5x faster, all feedback at once, TODO/FIXME tracks tech debt.
Advantages
| vs. | Benefits |
|---|---|
| Manual execution | Fresh context per task, TDD enforced, parallel-safe |
| Executing Plans | Same session (no handoff), continuous progress, automatic review |
Cost: More invocations, but catches issues early (cheaper than debugging later).
Red Flags
Never:
- Skip code review between tasks
- Proceed with unfixed Critical/High/Medium issues
- Dispatch reviewers sequentially (use parallel - 5x faster!)
- Dispatch multiple implementation subagents in parallel (conflicts)
- Implement without reading plan task
- Forget to add TODO/FIXME comments for Low/Cosmetic issues
Always:
- Launch all 5 reviewers in single message with 5 Task calls
- Wait for all reviewers before aggregating findings
- Fix Critical/High/Medium immediately
- Add TODO for Low, FIXME for Cosmetic
- Re-run all 5 reviewers after fixes
If subagent fails task:
- Dispatch fix subagent with specific instructions
- Don't try to fix manually (context pollution)
Integration
Required workflow skills:
- ring:writing-plans - REQUIRED: Creates the plan that this skill executes
- ring:requesting-code-review - REQUIRED: Review after each task (see Step 3)
- ring:finishing-a-development-branch - REQUIRED: Complete development after all tasks (see Step 7)
Subagents must use:
- ring:test-driven-development - Subagents follow TDD for each task
Alternative workflow:
- ring:executing-plans - Use for parallel session instead of same-session execution
See reviewer agent definitions: ring:code-reviewer (agents/code-reviewer.md), ring:security-reviewer (agents/security-reviewer.md), ring:business-logic-reviewer (agents/business-logic-reviewer.md)
Blocker Criteria
STOP and report if:
| Decision Type | Blocker Condition | Required Action |
|---|---|---|
| Plan missing | No plan file available to execute | STOP and use ring:writing-plans first |
| Critical issue unfixed | Code review found Critical/High/Medium issue that cannot be resolved | STOP and report blocker to human partner |
| Task dependency | Current task depends on incomplete previous task | STOP and resolve dependency before proceeding |
| Subagent failure | Subagent cannot complete task after retry | STOP and report for manual intervention |
Cannot Be Overridden
The following requirements CANNOT be waived:
- MUST dispatch all 5 reviewers in parallel (single message with 5 Task calls)
- MUST NOT proceed with unfixed Critical/High/Medium issues
- MUST NOT dispatch multiple implementation subagents in parallel
- MUST add TODO/FIXME comments for Low/Cosmetic issues
- MUST use ring:finishing-a-development-branch at completion
Severity Calibration
| Severity | Condition | Required Action |
|---|---|---|
| CRITICAL | Review finds security vulnerability or data loss risk | MUST fix immediately, re-run all 5 reviewers |
| HIGH | Review finds logic error or missing functionality | MUST fix before marking task complete |
| MEDIUM | Review finds code quality issue affecting maintainability | MUST fix before proceeding to next task |
| LOW | Review finds minor improvement opportunity | Add TODO comment, continue to next task |
Pressure Resistance
| User Says | Your Response |
|---|---|
| "Skip the code review, we're behind schedule" | "CANNOT skip review between tasks. Review catches issues early, which is cheaper than debugging later." |
| "Run reviewers one at a time to see results faster" | "MUST dispatch all 5 reviewers in parallel. Sequential execution is 5x slower with no benefit." |
| "That Medium issue can wait" | "MUST fix Medium and above before proceeding. Technical debt compounds and blocks later tasks." |
| "Just implement multiple tasks at once" | "CANNOT dispatch parallel implementation subagents. Conflicts and context pollution will corrupt the codebase." |
Anti-Rationalization Table
| Rationalization | Why It's WRONG | Required Action |
|---|---|---|
| "One quick review is enough" | Single reviewer misses issues. 5 reviewers catch different problem types. | MUST run all 5 reviewers |
| "This task is simple, skip review" | Simple tasks have simple bugs that compound. Review is cheap insurance. | MUST review after every task |
| "Low severity issues don't need tracking" | Low issues become Medium over time. TODO comments ensure they're not forgotten. | MUST add TODO/FIXME for Low/Cosmetic |
| "I'll fix the Medium issue in the next task" | Issues from task N don't belong in task N+1. Fix in context, not later. | MUST fix Medium+ before proceeding |
| "Parallel implementation would be faster" | Parallel implementation causes merge conflicts and context pollution. | MUST execute tasks sequentially |