Subagent Development

---
name: Subagent-Driven Development
description: Guidance for assigning, coordinating, and reviewing focused subagent work.
---

# Subagent-Driven Development

> Fresh agents per task. Two-stage review. Status protocol. No context bleeding.

## Triggers

- Multi-domain task requiring parallel agent work
- `/sc:spawn` produces a task hierarchy to execute
- User requests agent-based task delegation
- Complex implementation spanning multiple technical domains

## Core Principles

### 1. Fresh Agent Per Task

Each subagent gets a **fresh context** with only what it needs:
- The specific task description
- Relevant file paths and content
- Acceptance criteria with a test that defines "done"
- No leaked context from other tasks

**Why**: Context bleeding causes agents to make assumptions from unrelated tasks, producing subtle bugs.

### 2. Status Protocol

Every subagent MUST report status using exactly one of these:

| Status | Meaning | Action Required |
|--------|---------|-----------------|
| `DONE` | Task complete, all tests pass | Proceed to review |
| `BLOCKED` | Cannot proceed, needs external input | Orchestrator resolves blocker |
| `NEEDS_CONTEXT` | Missing information to complete task | Provide specific context requested |
| `DONE_WITH_CONCERNS` | Complete but with flagged issues | Review concerns before accepting |

### 3. Two-Stage Review

Every subagent's output goes through **two reviews** before acceptance:

**Stage 1: Spec Compliance**
```
- Does the output match the task description exactly?
- Are all acceptance criteria met?
- Does the test that defines "done" pass?
- Are there any out-of-scope changes?
```

**Stage 2: Code Quality**
```
- Does the code follow project conventions?
- Are there security issues? (injection, auth, secrets)
- Is error handling adequate?
- Is the code testable and maintainable?
```

If either stage fails, the subagent output is **rejected with specific feedback**.

## Domain Grouping Strategy

When spawning multiple agents, group by domain to minimize cross-cutting concerns:

| Domain | Typical Tasks |
|--------|---------------|
| **Data Layer** | Schema, migrations, queries, ORM models |
| **API Layer** | Routes, controllers, validation, serialization |
| **Business Logic** | Services, domain models, rules |
| **Infrastructure** | Docker, CI/CD, deployment, monitoring |
| **Frontend** | Components, state, routing, styling |
| **Testing** | Test infrastructure, fixtures, mocks |

**Rule**: Tasks within the same domain can share an agent. Tasks across domains MUST use separate agents.

## Orchestration Pattern

```
1. DECOMPOSE: Break the task into domain-grouped subtasks
2. SPEC: Write acceptance criteria + failing test for each subtask
3. DISPATCH: Launch one agent per domain group (parallel where independent)
4. MONITOR: Collect status from each agent
5. REVIEW: Two-stage review of each agent's output
6. INTEGRATE: Merge outputs, run full test suite, resolve conflicts
7. VERIFY: Trigger verification-before-completion
```

## Integration

- Task decomposition comes from `/sc:spawn`
- Each subtask follows `test-driven-development`
- Reviews follow `/review` command patterns
- Final integration uses `verification-before-completion`
- Use `git-worktrees` for isolation when agents modify overlapping files