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