subagent-driven-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