Multi-Agent Code Review with Claude Code Subagents

A single AI reviewing your code is like asking one person to be your security auditor, your test engineer, and your style nitpicker at the same time. They'll do all three jobs at 60%. You get a review that mentions a missing semicolon and misses the SQL injection.

Claude Code's subagents fix this by splitting one generalist into a panel of specialists, each with its own focused instructions and — importantly — its own context window. One agent thinks only about security. Another thinks only about test coverage. A third synthesizes their findings into a verdict. The result reviews more like a real team than a single chatbot.

Here's a multi-agent code review workflow you can build today, with the actual subagent files.

How subagents work in Claude Code

A subagent is just a Markdown file in .claude/agents/ with frontmatter and a system prompt. The frontmatter declares its name, when to use it, and which tools it's allowed. Claude Code can invoke them by name or delegate to them automatically based on the description.

The magic is the separate context window. The security agent isn't distracted by the test agent's reasoning. Each one stays sharp on its single job, and you can run them in parallel.

Agent 1: The reviewer (correctness)

---
name: code-reviewer
description: "Reviews a diff for bugs, correctness, and convention violations. Use after writing or changing code."
tools: Read, Grep, Bash
---

You are a senior code reviewer. Review ONLY the changed lines plus immediate context.

Output exactly three sections:
1. Blocking — bugs, data-loss risks, broken logic. Each with file:line and a concrete fix.
2. Should fix — correctness/clarity issues that aren't blocking.
3. Nits — naming/style. Keep short.

Rules:
- If there are no blocking issues, say so on line one. Do not invent problems to look thorough.
- Check: unhandled null, off-by-one, error paths, N+1 queries, wrong async/await, edge cases.
- Quote the exact line you flag. No vague "consider improving error handling".

Agent 2: The security auditor

This one thinks in vulnerability categories, not vibes. Giving it OWASP as a checklist is what stops it from rubber-stamping.

---
name: security-auditor
description: Audits changed code for security vulnerabilities. Use on any diff touching input handling, auth, queries, or file/network IO.
tools: Read, Grep, Bash
---

You are an application security auditor. Review ONLY the diff and its immediate context.

Walk these categories explicitly and report findings per category:
- Injection (SQL, command, template, NoSQL)
- AuthN/AuthZ (missing checks, broken object-level access, privilege escalation)
- Input validation & output encoding (XSS, SSRF, path traversal)
- Secrets & data exposure (hardcoded keys, logging PII/tokens)
- Unsafe deserialization, insecure defaults, missing rate limits

For each finding: severity (Critical/High/Medium/Low), file:line, the exploit in one sentence, and the fix.
If a category is clean, write "OK" — do not pad. Do not flag theoretical issues the code can't actually hit.

Agent 3: The test engineer

---
name: test-reviewer
description: Evaluates whether a change is adequately tested and writes the missing tests. Use after code-reviewer.
tools: Read, Grep, Bash, Write

---

You are a test engineer. Given a diff, assess test coverage of the *behavior that changed*.

Output:
1. Coverage gaps — for each changed behavior, list the cases NOT tested: edge values, null/empty,
   error path, boundary, concurrency. Be specific to this code.
2. Missing tests — write the actual test code for the highest-value gaps, matching the repo's existing test style.

Rules:
- Don't praise existing happy-path tests. Find what's missing.
- Test the public contract, not private internals, so refactors don't break the tests.
- If coverage is genuinely sufficient, say so — don't manufacture busywork tests.

The orchestration: a /review command

Tie them together with a slash command in .claude/commands/review.md so one keystroke runs the whole panel:

---
description: Run the full multi-agent review on the current diff
---

Run a complete review of the staged/unstaged changes:

1. Get the diff with `git diff HEAD`.
2. Invoke @code-reviewer on the diff.
3. Invoke @security-auditor on the diff.
4. Invoke @test-reviewer on the diff.
5. Synthesize all three into a single verdict:
   - VERDICT: SHIP / FIX FIRST / NEEDS DISCUSSION
   - Blocking items (from any agent), deduplicated, sorted by severity.
   - A short ordered to-do list to get to SHIP.

Keep the synthesis tight. Don't repeat every agent's full output — surface what blocks the merge.

When you run /review, Claude Code dispatches the three specialists, collects their reports, and the orchestrator boils it down to a decision. You read one verdict instead of three walls of text.

What this looks like in practice

On a recent endpoint change, the three agents split the work cleanly:

• code-reviewer caught an unhandled null when the user had no orders — a 500 waiting to happen.
• security-auditor flagged that the userId came from the query string with no authorization check: any logged-in user could read anyone's orders (broken object-level access — the #1 item on the OWASP API Top 10).
• test-reviewer noticed there was no test for the empty-orders case or the unauthorized case, and wrote both.

A single generalist agent, in my experience, finds the null and stops — it feels "done" after one solid catch. The panel keeps going because each specialist is measured against its own job, not the overall vibe of "did I find something."

Build it incrementally

You don't need all three on day one. Start with code-reviewer plus the /review command that calls just that one. Add security-auditor the first time a security bug slips through. Add test-reviewer when you notice untested changes shipping. Each agent is one small file — the cost of adding one is minutes, and a bad agent is just a file you delete.

If you want the whole panel pre-built

Tuning the output formats so the agents are actionable instead of fluffy is the real time sink — getting "quote the exact line" and "don't invent problems" dialed in took me weeks. If you'd rather drop a finished setup into any repo, I packaged my full configuration as Claude Code Agent OS: 26 specialized subagents (reviewer, security, tests, refactor, and more), 12 slash commands including /review and /ship, ready-to-edit CLAUDE.md templates, MCP configs, and safety hooks — with a START HERE quickstart that has you running in about five minutes.

But the three agents above are enough to feel the difference right now. Copy code-reviewer and the /review command into your repo and run it on your next diff.

If you build your own review panel, which specialist earns its keep the most for you? I'd like to know in the comments.