The 12 Claude Code Subagents Worth Setting Up First (and What Each One Does)

Search for Claude Code subagents and you'll land on GitHub repos with 100+ agents and no opinion about which ones matter. That's a parts catalog, not advice. Here is the opposite: the twelve subagents that earn their place in a real workflow, what each one does, and why it made the cut.

Quick refresher: a subagent is a markdown file in .claude/agents/ with a description (which tells the main session when to delegate), a system prompt, and optionally a restricted tool list. It runs in its own context window and reports back only results. That means better focus, cleaner main-session context, and scoped permissions.

The four that pay for themselves in week one

1. Code reviewer

The single highest-value subagent. Give it read-only tools and a prompt that reviews for correctness first, style second — checking the diff against how the change could actually fail, not against a linter's taste. Because it runs in a fresh context, it reviews your changes without the bias of having written them.

2. Debugger

A root-cause specialist: reproduce first, hypothesize, instrument, confirm, then fix. Delegating debugging keeps twenty files of stack-trace spelunking out of your main session's context — the subagent burns its own window on the search and returns just the diagnosis.

3. Test writer

Writes tests that assert behavior rather than implementation, and knows your framework conventions. Pair it with the reviewer: one agent writes the change, another writes the tests, and neither inherits the other's assumptions.

4. Codebase explorer

A read-only researcher for "where does X happen?" and "how do these modules fit together?" questions. This is the purest use of context isolation — exploration is exactly the work that bloats a main session fastest.

The four for shipping safely

5. Security auditor

Reviews changes for injection, authz gaps, secrets in code, and unsafe input handling. Restrict it to read-only tools and run it on anything touching auth, payments, or user data. A dedicated agent applies a checklist consistently; an ad-hoc prompt applies it when you remember.

6. Refactoring specialist

Constrained to behavior-preserving changes: it must keep tests green and is explicitly forbidden from "improving" functionality along the way. That constraint is the whole point — refactors go wrong when scope creeps.

7. Performance profiler

Measures before it optimizes. Its prompt requires evidence — a benchmark, a flame graph, a query plan — before any change, which kills the guess-driven optimization Claude will otherwise happily do.

8. Database/migrations agent

Knows your schema conventions, writes reversible migrations, and flags destructive operations instead of running them. Databases are where "move fast" goes to die; a specialist with guardrails is worth the file.

The four for everything around the code

9. Docs writer

Keeps READMEs, API docs, and changelogs in sync with reality. Prompt it to document what the code does now — not what the commit messages claim.

10. PR/release manager

Drafts PR descriptions from the actual diff, writes release notes, and checks that the branch state matches your team's conventions before anything ships.

11. Dependency auditor

Reviews new dependencies (size, maintenance, license, CVEs) and handles upgrade PRs with changelogs read, not skimmed. Cheap insurance against supply-chain surprises.

12. Orchestrator

The meta-agent: takes a large task, splits it into independent pieces, and fans them out to the specialists above — sequentially when steps depend on each other, in parallel when they don't. This is the one that turns eleven individual agents into a team. (If you're running agents in parallel, read the token-cost guide first.)

What makes a subagent actually good

Four things separate agents that get used from agents that rot in a folder:

• A description written for the delegator. The main session decides delegation by reading descriptions. "Use this agent after writing or modifying code to review the changes" gets used; "An expert code reviewer" does not.
• Minimal tools. Reviewers and explorers should be read-only. Fewer tools means fewer permission prompts, fewer surprises, and more focus.
• One job. A "full-stack expert" agent is just the main session with extra steps. Narrow agents delegate cleanly.
• An output contract. Tell the agent exactly what to return — a verdict, a diff, a ranked list — so the main session gets a result, not a transcript.

FAQ

Keep reading