Code Review

Reviews code changes using specialized reviewers. Uses agent teams when available for richer cross-validation.

When to Use

• •After completing a plan section (during iterative:implementing skill)
• •Before finishing work and creating a PR
• •When you want feedback on any code changes
• •Can be invoked standalone

Severity Scale

All reviewers use the same 4-level scale:

Reviewers

Each reviewer reports only issues they're confident about, using the severity scale above.

Review Modes

Full Mode (default)

Uses all 5 reviewers for comprehensive coverage.

Quick Mode

Uses 2-3 reviewers. Auto-detect from changed files when the caller doesn't specify a type:

How to Run

Step 1: Determine scope.

Identify what code to review using the appropriate git diff range:

• •From implementing (section-level): The caller provides a baseline SHA (captured at section start) and plan context. Use git diff <baseline-sha>..HEAD to scope to only the section's changes. Get changed files with git diff --name-only <baseline-sha>..HEAD.
• •From implementing (final/branch-level): The caller provides a merge-base scope. Use git diff $(git merge-base HEAD <base>)..HEAD for all branch changes.
• •Standalone: Detect base branch (git rev-parse --verify origin/main >/dev/null 2>&1 && echo main || echo master). Use git diff $(git merge-base HEAD <base>)..HEAD to identify changed files. If no commits on branch, fall back to unstaged changes (git diff).
• •Explicit files: If the caller specifies files, use those.

Get the changed file list with --name-only to determine Full or Quick mode from change analysis. The full diff content is what reviewers analyze.

Step 2: Spawn reviewers.

Create an agent team (e.g. TeamCreate in Claude Code, spawn_agent in Codex), then spawn reviewers as teammates. In Full mode, spawn all 5. In Quick mode, spawn 2-3 based on change type (see Review Modes above). If the team already exists (e.g., from an interrupted run), reuse it — read its config, check which reviewers are already present, and spawn only the missing ones.

Tell the user:

Using Agent Team 🐝 — reviewers will run as teammates who can cross-validate findings.

Spawn each reviewer with a prompt that includes the review context:

Review the following changes for [their focus area].

Changed files: [file list from git diff or caller] What was built: [plan section summary — include if available from implementing] Plan test scenarios: [relevant test scenarios from the plan — include if available, for correctness and testing reviewers]

You're on a review team with [list other active reviewers]. After your initial review, read what the other reviewers found and message them directly if you see cross-domain issues. Challenge each other's findings.

Your job is to review and report findings — not to fix, remediate, or modify the code. Only report issues you're confident about. When done, send your findings to the team lead (e.g. SendMessage in Claude Code, send_input in Codex). Use the severity scale: Critical / High / Medium / Low.

Step 3: Collect findings.

Wait for all reviewers to send their findings. When you receive a reviewer's message, do not output or echo its content — silently collect it. Only output once in Step 4 when assembling the final results. A brief one-line status like "All 5 reviewers have reported" is fine when ready to proceed.

Step 4: Synthesize and present.

Shut down all teammates (send shutdown requests), then delete the team. Assemble the final output:

1. •Deduplicate. Merge findings that multiple reviewers flagged — attribute to the most relevant reviewer, note cross-reviewer agreement.
2. •Format. Start with a ### Strengths section highlighting what's well done (with file:line refs). Format each reviewer's findings as a table — one issue per row, same structure for every section. Use ### Reviewer Name headers. Separate sections with clear whitespace.
3. •Verdict. End with a --- separator followed by:

Verdict: Ready to merge / Ready with fixes / Not ready

Reasoning: [1-2 sentences — overall quality assessment]

Fix order: [If fixes needed — prioritized: critical first, then high, etc.]

Do not include time estimates.

Language-Agnostic

This skill does NOT use language-specific reviewer agents (no Rails-reviewer, Python-reviewer, etc.).

Instead, reviewers adapt their criteria to the language/framework based on project context (which teammates load automatically). This keeps the skill simple and avoids maintaining parallel reviewers per language.

Multiple Rounds

After fixing issues, run another round. Each round creates a fresh team (the previous team was deleted). Run the full Step 2–4 flow again.

Continue until:

• •No critical or high issues remain
• •User chooses to proceed

After Review

This skill only reviews. Do not invoke other skills (implementing, tech-planning, etc.) after presenting results.

When invoked standalone or from implementation-wrapup, ask the user to choose:

• •Fix issues and re-review (Recommended)
• •Fix issues and proceed to [name the actual next step based on context, e.g., "create a PR" if code is ready]
• •Continue without changes

When invoked from iterative:implementing, return findings directly — implementing owns the review loop and decides whether to re-review or continue to the next section.

Fallback: If Agent Teams/Swarms are Unavailable

If agent teams/swarms are not available, spawn the reviewers in parallel as independent subagents instead of teammates. Each analyzes independently. Skip the cross-validation instruction. Everything else (Steps 1, 3, 4, output format) stays the same.