# Subagent Cookbook — 15 Copy-Paste Dispatch Recipes
> [繁體中文](./subagent-cookbook.md) | [简体中文](./subagent-cookbook.zh-Hans.md) | **English**
> 📋 **What this is**: [Stage 5.5](../stages/05-claude-code-ecosystem.en.md#55--subagents-claude-codes-native-multi-agent-mechanism--2025-new-feature) teaches the concept of subagents. This cookbook teaches you how to **use them today**: 15 scenarios, each with “which subagent to use + a complete prompt template you can copy-paste + when not to use it.”
>
> ⚠️ **First time here? Read Stage 5.5’s “Which subagents can you dispatch?” and “decision table” sections first**. Once you understand what a subagent is and which ones Claude Code includes, come back and pick a recipe.
---
## How to Read This Cookbook
Each recipe uses the same 4-part structure:
| Section | Content | Why it exists |
|:---|:---|:---|
| **Scenario** | A concrete situation you might run into today | Find a recipe from “I have X problem,” not from “I want to use a subagent” |
| **Subagent** | Which one to use (Claude Code’s built-in name) | Copy the name directly; no guessing |
| **Prompt Template** | Copy-paste-ready instruction text | No need to invent the prompt yourself |
| **When Not to Use It** | A better alternative than using a subagent | Avoid overkill |
> 💡 **How to actually dispatch a subagent**: in your Claude Code terminal conversation, **type or paste the prompt template directly**. That is all. Claude sees the instruction, automatically uses the **Agent tool** (Claude Code’s internal dispatch mechanism) to find the right subagent, runs it, and returns a short summary to the main session. **No slash command or special syntax is required**.
>
> 📌 **Subagent vs slash command**: `/agents` is a list command, **not how you invoke a subagent**. To dispatch a subagent, type ordinary prompt text directly. For complete comparison tables (subagent vs skill / vs slash command / description router), see [Stage 5.5 §Common Confusing Concepts Clarified](../stages/05-claude-code-ecosystem.en.md#55--subagents-claude-codes-native-multi-agent-mechanism--2025-new-feature).
---
## First, Check Which Subagents You Have Available
Run `/agents` inside your Claude Code session. It lists every subagent currently available to you: built-in, plugin-provided, and custom.
**The 7 built-in Claude Code subagents**: `general-purpose` / `code-reviewer` / `Explore` / `Plan` / `frontend-developer` / `claude-code-guide` / `statusline-setup` (as of 2025-11; this may change).
> 📌 **Each built-in subagent's purpose + the "task X → use subagent Y" decision table live canonically at [Stage 5.5 §Which subagents can you dispatch?](../stages/05-claude-code-ecosystem.en.md#which-subagents-can-you-dispatch)** — this cookbook focuses on the 15 dispatch recipes; treat Stage 5.5 as the source of truth for the built-in list and selection logic.
> 💡 **If your `/agents` list does not match this cookbook**: you may have installed plugins, or your Claude Code version may differ. **When a recipe name does not match, use the closest available subagent**. For example, if you do not have `Explore`, `general-purpose` can still run a search task.
After confirming what is available, use the 15 recipes below: **find the recipe that matches your scenario, then copy the Prompt Template into the Claude Code conversation**.
---
## The 15 Recipes
### Recipe 1: Review a batch of new code before committing
**Scenario**: You just wrote ≥ 50 lines of new code and want to commit, but you are worried you missed a bug or security issue.
**Subagent**: `code-reviewer`
**Prompt Template**:
```
Review the staged changes in this repo (git diff --cached).
Focus on: (1) security issues (hardcoded secrets, SQL injection, XSS),
(2) error handling gaps, (3) missing tests, (4) violations of CLAUDE.md
conventions. Per-category PASS/FAIL + concrete fix for each issue with
file:line reference + overall verdict (APPROVE / REQUEST CHANGES).
```
**When Not to Use It**: A < 20-line typo or formatting fix. Just scan `git diff` yourself; do not spend subagent tokens.
---
### Recipe 2: Enter a new repo and find where to start reading
**Scenario**: You cloned someone else’s repo, `README.md` does not clearly explain the entry point, and you do not want to dig randomly.
**Subagent**: `Explore`
**Prompt Template**:
```
Map the entry points and core structure of this codebase. Report:
(1) main entry script(s) — what file gets run first,
(2) core module organization — top 3-5 directories and what each does,
(3) test directory layout,
(4) any "where to start reading" guidance in docs/.
Under 300 words with file paths.
```
**When Not to Use It**: You already know the exact file path to read. Use the Read tool directly.
---
### Recipe 3: Design a refactor / migration plan before touching code
**Scenario**: You need to refactor a large module or do a framework migration, but the steps are unclear and you want a plan first.
**Subagent**: `Plan`
**Prompt Template**:
```
Design a step-by-step plan to refactor (currently a single
file with tight coupling) into clear, testable components with explicit
interfaces. Include: (1) phased breakdown (≤ 5 phases), (2) which files
touched per phase, (3) what tests gate each phase, (4) rollback strategy
if a phase fails. Don't write code — just the plan.
```
**When Not to Use It**: The refactor only touches 1-2 files. Start directly; the planning overhead is not worth it.
---
### Recipe 4: Review multi-file / cross-locale parity
**Scenario**: You changed zh-TW + zh-Hans + en mirror files and want to confirm the three versions still match.
**Subagent**: `code-reviewer`
**Prompt Template**:
```
Review the staged diff for cross-locale parity across the 3 locale
variants of (.md / .zh-Hans.md / .en.md). Check: (1) same
section structure (## headers match), (2) same table row counts, (3)
same required terms present in each locale, (4) locale conventions
correct (zh-Hans uses "" not 「」; en uses English). Report per-file
PASS/FAIL.
```
**When Not to Use It**: You only changed one locale. There is no parity issue to check.
---
### Recipe 5: Multi-source fact-check / research
**Scenario**: You need to write a cited statement, but you are not sure whether multiple sources are talking about the same thing and need cross-checking.
**Subagent**: `general-purpose`
**Prompt Template**:
```
Fact-check this claim: "". Search for: (1) primary source / official
docs / paper, (2) 2-3 independent secondary sources, (3) any contradictions
or version differences. Report: confirmed / contradicted / nuanced, with
direct quotes and URLs. Under 400 words.
```
**When Not to Use It**: You already have one authoritative source. Read that source directly.
---
### Recipe 6: Find where a symbol / function is defined
**Scenario**: A codebase imports `parse_config` everywhere, and you want to know which file implements it.
**Subagent**: `Explore`
**Prompt Template**:
```
Find where `` is defined in this codebase. Report: (1) the
file:line where it's defined, (2) what it does (1-line summary), (3) which
files import / use it (top 5). Use Grep, not full file reads.
```
**When Not to Use It**: Your IDE’s “Go to definition” already jumps there. The IDE is faster than a subagent.
---
### Recipe 7: Compare whether several papers / sources agree on a claim
**Scenario**: You are writing a literature review. Three papers disagree about the same thing, and you do not know which one to trust.
**Subagent**: `general-purpose`
**Prompt Template**:
```
Find and compare 3 independent sources on the topic . For each
source, capture: title + author + year + URL. Then report: (1) what
they agree on, (2) where they disagree (with direct quotes), (3) which
is most recent / authoritative, (4) suggested phrasing if you had to
summarize the consensus. Flag if a key source is behind a paywall and
unreadable.
```
**When Not to Use It**: All 3 papers are by the same author or lab. There is no real multi-perspective comparison.
---
### Recipe 8: Release commit security audit
**Scenario**: You are about to ship v1.0 or a major version and want one final security pass.
**Subagent**: `code-reviewer`
**Prompt Template**:
```
Pre-release security audit for (use git log to find the
relevant commit range since last release). Check: (1) hardcoded
credentials / API keys, (2) eval() / exec() / shell injection risks,
(3) deprecated dependencies with known CVEs, (4) any auth / session
handling changes since last release, (5) public API surface changes
(breaking? documented?). Per-category PASS/FAIL + remediation per
finding.
```
**When Not to Use It**: A patch release or hotfix that changes one line. Manual review takes < 1 minute.
---
### Recipe 9: Assess the blast radius of an architecture change
**Scenario**: You want to change a base class or shared utility, but you do not know how many files it will affect.
**Subagent**: `Plan`
**Prompt Template**:
```
Assess the blast radius of changing . Report: (1) direct
dependents (which files import this), (2) indirect dependents (transitive
imports), (3) tests that gate the change, (4) suggested rollout order
(safest → riskiest), (5) feature flag / kill switch strategy if available.
Don't make the change yet — just the impact analysis.
```
**When Not to Use It**: The change only affects internals of one file. There is no blast-radius problem.
---
### Recipe 10: Spawn parallel subagents for the same task across multiple targets
**Scenario**: Four branch files all need the same “academic-style audit,” and you want to run all four in parallel.
**Subagent**: `general-purpose` × N (spawn several at the same time)
> 💡 **How to request parallel work**: Put all four files in one prompt and ask Claude to assign them to separate subagents. Check the run status after sending it; requesting parallel work does not prove it ran in parallel.
**Prompt Template** (replace these with your four file paths):
```
Use separate subagents to audit these files in parallel: A.md, B.md, C.md, D.md.
Each subagent reports on one file. Check: (1) over-engineering
jargon without first-use explanation, (2) clarity (long sentences,
vague pronouns), (3) unsupported % claims, (4) persona-fit (wrong
technical level for the file's stated target audience — see the
file's banner / intro callout for who it's for). Report 4-category
PASS/FAIL + fix-list with line numbers. Under 500 words.
```
**When Not to Use It**: There is only one target. Invoke one subagent directly; do not over-orchestrate.
---
### Recipe 11: Find similar implementations across repos
**Scenario**: You saw a pattern in one repo and want to know whether another repo has a similar implementation.
**Subagent**: `Explore`
**Prompt Template**:
```
In , search for code patterns similar to: . Report:
(1) up to 5 candidates with file:line, (2) brief description of each,
(3) which is most idiomatic for this codebase's style.
```
**When Not to Use It**: You have a specific function name to find. Use Recipe 6 / `Explore` with a precise grep; it will be faster.
---
### Recipe 12: LLM-as-judge eval (structured PASS / FAIL)
**Scenario**: You ran 100 test cases and need to judge whether each output meets the spec, without reading them all manually.
**Subagent**: `general-purpose`
**Prompt Template**:
```
Evaluate the agent outputs in against the spec stated
in the file's first 5 lines (or in ). For each row: PASS /
FAIL with 1-sentence reason. Aggregate: pass rate + top-3 failure modes.
Output as structured JSON: {"case_id": "...", "verdict": "PASS|FAIL",
"reason": "..."}.
```
**When Not to Use It**: There are < 5 cases; read them yourself. Or the evaluation requires subjective judgment; an LLM judge is not reliable enough.
---
### Recipe 13: UI component design / accessibility audit
**Scenario**: You wrote a React component and want to confirm ARIA, keyboard navigation, and responsive behavior are all correct.
**Subagent**: `frontend-developer`
**Prompt Template**:
```
Audit for: (1) ARIA roles + labels (screen reader
compatibility), (2) keyboard navigation (tab order, Enter / Esc / arrows
behavior), (3) responsive breakpoints (mobile 360px / tablet 768px /
desktop 1280px), (4) color contrast (WCAG AA), (5) touch target size
(≥ 44px). Report per-category findings + fixes.
```
**When Not to Use It**: Pure backend or CLI tooling. There is no UI to audit.
---
### Recipe 14: Ask how to use a Claude Code feature
**Scenario**: You forgot how to configure hooks, forgot the frontmatter fields for slash commands, or want to look up documentation.
**Subagent**: `claude-code-guide`
**Prompt Template**:
```
How do I ? Show: (1) minimum
config in settings.json, (2) example hook script (Python or shell),
(3) 1 common gotcha, (4) where in the official docs to read more.
```
**When Not to Use It**: You have already written this a few times. Looking at your own `~/.claude/settings.json` example is faster.
---
### Recipe 15: Implement React form validation logic
**Scenario**: You need to build a sign-up form with email format validation, password strength, and real-time validation.
**Subagent**: `frontend-developer`
**Prompt Template**:
```
Implement a React sign-up form with: (1) email format validation
(real-time, debounce 300ms), (2) password strength meter (≥ 8 chars,
mixed case, digit, symbol), (3) inline error messages with ARIA
live region, (4) submit button disabled until valid. Use . Include: component code, validation schema,
1 happy-path test, 1 error-path test.
```
**When Not to Use It**: You are not using a React stack. Use the matching Vue / Svelte subagent, or `general-purpose`.
---
## Recipe Index (by Subagent Type)
Not sure which subagent to use? Look it up by **task type**:
| Subagent | Recipes |
|:---|:---|
| `code-reviewer` | **1** (pre-commit review) / **4** (cross-locale parity) / **8** (release security audit)|
| `Explore` | **2** (new codebase) / **6** (find symbol) / **11** (cross-repo similar code)|
| `Plan` | **3** (refactor plan) / **9** (blast radius)|
| `general-purpose` | **5** (fact-check) / **7** (multi-paper compare) / **10** (parallel multi-target) / **12** (LLM-as-judge eval)|
| `frontend-developer` | **13** (a11y audit) / **15** (React form)|
| `claude-code-guide` | **14** (Claude Code feature lookup)|
---
## When NOT to Use a Subagent
Subagents are not free. Every dispatch **spends tokens and adds latency**. In the 4 situations below, **do not use a subagent**; doing it yourself is more efficient:
1. **The task takes < 5 minutes to do yourself** — This is overkill; the subagent overhead is not worth it.
2. **The result needs step-by-step user feedback** — A subagent is “dispatch it, let it run, get one final report.” It cannot ask you midway. Tasks that need iterative confirmation should stay in the main session.
3. **The task needs the main session’s context memory** — A subagent has an **independent context window** and cannot see earlier discussion in the main session. Tasks that depend on references like “the X we discussed earlier” are a bad fit.
4. **The task involves conversation-level judgment** — For example, “how should we weigh this architecture decision?” needs collaborative discussion and should not be thrown to a subagent.
> 💡 **A quick way to decide**: if you can describe the task as “**write a complete brief for a stranger to pick up**,” it is a good fit for a subagent. If it needs “**let’s talk this through**,” keep it in the main session.
---
## Next Steps
- **Understand the full theory** (how subagents differ from skills / MCP, and the 3 multi-agent mechanisms) → [Stage 5.5](../stages/05-claude-code-ecosystem.en.md#55--subagents-claude-codes-native-multi-agent-mechanism--2025-new-feature)
- **CLI daily-use playbook** → [`tracks/cli/A3-cli-production.en.md` Playbook 4](../tracks/cli/A3-cli-production.en.md#-playbook-4-dispatching-subagents-for-independent-tasks)
- **See where subagents fit in the agent paradigm map** → [`resources/agent-paradigms.en.md`](./agent-paradigms.en.md#subagent--spawning-an-agent-inside-an-agent-runtime)
- **Glossary lookup** → [`resources/glossary.en.md` § 5. Claude Code Ecosystem — Subagent](./glossary.en.md#subagent)