code-review

Review local code changes by dispatching an isolated sub-agent — a fresh agent with no knowledge of the current session's implementation decisions. This eliminates the bias of reviewing your own work.

Process

1. Gather context for the sub-agent

Collect everything the reviewer needs:

# What changed
git log --oneline main..HEAD
git diff main...HEAD
git diff
git diff --cached

Also identify:

• Tech design doc path (if one exists in conversation context or commit messages)
• Which services/modules are touched
• Test files added or modified

2. Dispatch the sub-agent

Call the sub_agent tool with subagent_type: "code-review" — a read-only reviewer that starts with zero context. Pass it the diff range, file list, and tech design reference in the prompt — but NOT your implementation reasoning or conversation history.

If you need to review multiple independent changes (e.g., several PRs), dispatch each sub-agent with run_in_background: true so they run in parallel. Wait for the completion notifications and use the results from those notifications. Do not poll sub_agent_status while waiting; use sub_agent_status only if you suspect an agent is stuck or need to list running agents. For a single short review, a synchronous sub_agent call is fine.

The sub-agent prompt should follow the template in code-reviewer.md.

Fill in:

• {DESCRIPTION} — brief summary of what these changes do
• {TECH_DESIGN_PATH} — path to tech design doc (or "none")
• {BASE_SHA} / {HEAD_SHA} — git range
• {DIFF_STAT} — output of git diff --stat

If the sub_agent tool is not available in this session, perform the review yourself following the same template — and say explicitly in the report that the review was not isolated.

3. Act on the review

When the sub-agent returns its findings:

Receiving feedback — rules:

• Verify before implementing. Don't blindly agree.
• If any item is unclear, clarify ALL unclear items before fixing any.
• Implementation order: Critical → Important → Minor, test each fix individually.
• Push back with technical reasoning if the reviewer is wrong (missing context, doesn't apply to this codebase, YAGNI).
• No performative agreement ("Great point!", "You're absolutely right!"). Just fix and show the result.