home / skills / lerianstudio / ring / subagent-driven-development

subagent-driven-development skill

/default/skills/subagent-driven-development

This skill orchestrates autonomous subagents per task with automated between-task code review, delivering high-quality, fast iterations through strict quality

npx playbooks add skill lerianstudio/ring --skill subagent-driven-development

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
6.7 KB
---
name: ring:subagent-driven-development
description: |
  Autonomous plan execution - fresh subagent per task with automated code review
  between tasks. No human-in-loop, high throughput with quality gates.

trigger: |
  - Staying in current session (no worktree switch)
  - Tasks are independent (can be executed in isolation)
  - Want continuous progress without human pause points

skip_when: |
  - Need human review between tasks → use ring:executing-plans
  - Tasks are tightly coupled → execute manually
  - Plan needs revision → use brainstorming first

sequence:
  after: [ring:writing-plans, ring:pre-dev-task-breakdown]

related:
  similar: [ring:executing-plans]
---

# 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:**

1. **Track current module context:**
   ```
   current_module = None
   current_directory = "."
   ```

2. **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
   ```

3. **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)

Overview

This skill runs autonomous plan execution by dispatching a fresh subagent for each task and enforcing automated code review between tasks. It delivers continuous progress with quality gates, no human-in-the-loop, and high throughput while preventing context pollution. The workflow mandates TDD for implementations and repeats review/fix cycles until critical issues are resolved.

How this skill works

The skill loads a plan and creates a task queue. For each task it spawns a new subagent in a clean context to implement, test, commit, and report. After implementation, five specialized reviewers run in parallel (code, business logic, security, tests, nil-safety) and return structured findings; critical issues trigger a fix subagent and a repeat review loop until passing. Low and cosmetic items are recorded as TODO/FIXME comments and committed.

When to use it

  • You want continuous, same-session execution of a plan with no manual handoffs.
  • Tasks are mostly independent or can be reordered to reduce module context switches.
  • You need strict automated quality gates (security, tests, business logic, safety).
  • You want faster iteration by running reviewers in parallel rather than sequentially.

Best practices

  • Always dispatch one fresh subagent per task to avoid context pollution.
  • Run all five reviewers in a single message with parallel Task calls to get simultaneous feedback.
  • Treat Critical/High/Medium issues as blockers: dispatch a fix subagent and re-run all reviewers.
  • Record Low as TODO(review) and Cosmetic as FIXME(nitpick) with reviewer and date, then commit.
  • Reorder independent tasks to minimize working-directory or module context switches.

Example use cases

  • Implementing sequential features across multiple modules while preserving clean agent context.
  • Large refactor split into independent tasks that require automated safety and security checks.
  • High-throughput bug fixes where each fix needs immediate automated review and repeat fixes until clean.
  • End-to-end feature delivery where final branch finishing is automated after all reviews pass.

FAQ

What happens when reviewers report Critical issues?

A fix subagent is dispatched with explicit instructions; reviewers are re-run until all Critical/High/Medium issues are resolved.

Can tasks run in parallel?

Implementation subagents should not be run in parallel to avoid conflicts; reviewers run in parallel for speed.