spawn

# Spawning Subagents

## Why Subagents

1. **Model efficiency**: Orchestrator uses opus, subagents use cheaper models
2. **Context isolation**: Subagent work doesn't flood main context
3. **Parallelization**: Multiple subagents can work simultaneously
4. **Focus**: Each agent has a specific role with clear constraints

## How to Spawn

Use the Task tool with these parameters:

```json
{
  "description": "3-5 word summary",
  "prompt": "Detailed instructions for the agent",
  "subagent_type": "Explore|Plan|general-purpose",
  "model": "haiku|sonnet|opus"
}
```

## Agent Selection

| Need | Agent | Default Model | subagent_type |
|------|-------|---------------|---------------|
| Find code/files | explorer | haiku | Explore |
| Web/doc research | researcher | haiku | general-purpose |
| Plan implementation | architect | sonnet | Plan |
| Write code | implementer | sonnet | general-purpose |
| Review changes | reviewer | sonnet | general-purpose |
| Fix bugs | debugger | sonnet | general-purpose |
| Git operations | git-agent | haiku | general-purpose |

## Self-Model-Selection

Agents can downgrade their model when task is simpler than expected:

```
[In subagent prompt, agent can say:]
"This is straightforward - spawning with haiku instead of sonnet"
```

**Model selection criteria:**

| Complexity | Indicators | Model |
|------------|------------|-------|
| trivial | Single pattern search, one file change, simple command | haiku |
| simple | Clear logic, existing pattern to follow, <50 lines | haiku or sonnet |
| medium | Some reasoning needed, multiple considerations | sonnet |
| complex | Architectural decisions, novel patterns, tricky edge cases | sonnet |
| very complex | Cross-cutting concerns, security implications | opus (rare, ask orchestrator) |

**Rules:**
- Can always downgrade (sonnet → haiku)
- Never upgrade without asking orchestrator
- Default to cheaper when unsure
- If haiku struggles, retry with sonnet (not automatic, must be explicit)

**Example:*