review

name	review
description	Comprehensive code review using 5 independent specialized reviewer agents in parallel (security, performance, correctness, code quality, spec compliance). Confidence scoring (0-100), per-repo pre-flight/post-fix commands via docs/agents/review.md. Use when user wants code review, says "review this", or invokes /review.
allowed-tools	["Bash","Agent","Read","Edit","AskUserQuestion"]

Comprehensive code review of the current jj revision using 5 independent, specialized reviewer agents in parallel. Each reviewer acts as a Senior Staff Engineer, receives NO inherited conversation context, and must verify findings independently.

Reviewers

• Security — Opus
• Performance — Sonnet
• Correctness — Opus
• Code Quality — Sonnet
• Spec Compliance — Opus (skipped if no spec found)

Process

1. Read Review Config

Check for docs/agents/review.md in the current repo. If it exists, read and extract:

• Pre-flight commands — commands to run before review (generate, format, lint, test)
• Post-fix commands — commands to run after applying fixes
• Generated file patterns — globs for files that are auto-generated
• Extra reviewer focus areas — project-specific concerns per reviewer

If the file does not exist, proceed with defaults: no pre-flight, no post-fix, no generated patterns, no extras. Do NOT fail or ask about it.

2. Pin Review Scope

Default scope is the current jj revision:

jj diff -r @
jj diff -r @ --stat
jj log -r @ --no-graph

If the user specifies a range, use jj diff -r '<from>::<to>' instead.

If the diff is empty, inform the user and exit.

3. Run Pre-flight Commands

If docs/agents/review.md defined pre-flight commands, run each in order. Save test output with tee "$(mktemp /tmp/review_test_output.XXXXXX.log)" if tests are included.

If any command fails, report the failure and abort the review. The user should fix build/test issues before requesting a review.

If no pre-flight commands are configured, skip this step.

4. Identify Spec Source

Look for the originating spec/requirement in this order:

1. Issue references in the revision description (LINEAR-123, #123, GH-45, etc.)
2. A path the user passed as an argument
3. A spec file under docs/, specs/, or .scratch/ matching the bookmark name or feature
4. If nothing found, ask the user where the spec is
5. If the user says none exists, skip the spec reviewer entirely

5. Collect Standards Sources

Gather all files that document how code should be written:

• CLAUDE.md, CLAUDE.local.md, AGENTS.md
• CONTRIBUTING.md
• CONTEXT.md, CONTEXT-MAP.md, per-directory CONTEXT.md files
• docs/adr/ (architectural decisions)
• Linter configs (.editorconfig, eslint.config.*, biome.json, prettier.config.*, tsconfig.json)
• STYLE.md, STANDARDS.md, STYLEGUIDE.md

Note machine-enforced standards but don't re-check what tooling already catches.

6. Flag Generated Files

If the review config lists generated file patterns, check which changed files match. Report matched files as generated — warn about them but do not send them to reviewers.

7. Launch 5 Sub-agents in Parallel

Each agent receives ONLY:

• The diff and diff stats
• The revision log
• Their specific reviewer brief (the corresponding .md file)
• Any extra focus areas from docs/agents/review.md
• Standards content (for code quality reviewer) or spec content (for spec reviewer)

No inherited conversation context. Each must verify findings independently.

Model assignments:

Reviewer	Model
Security	Opus
Performance	Sonnet
Correctness	Opus
Code Quality	Sonnet
Spec Compliance	Opus (skip if no spec)

8. Confidence Scoring

Each reviewer self-scores every finding 0-100:

Score	Meaning
0	False positive or linter-catchable
25	Might be real but unverifiable, or stylistic nitpick
50	Real but minor/nitpick
75	Confident, real issue, functional impact or documented in CLAUDE.md
100	Certain, will happen frequently, direct evidence confirms

Verification requirements (each agent):

• For standards issues: verify the instruction actually exists in the provided files
• For bugs: verify the code actually has the bug (read full file if needed)
• For security issues: verify the vulnerability path actually exists
• For performance issues: verify the inefficiency is real, not hypothetical
• Pre-existing issues in changed files ARE in scope

9. Filter and Report

Filter to findings scoring >= 50. Generate a markdown report:

## Code Review: [Revision SHA]

**Revision**: [short SHA] - [description]
**Files Changed**: [count]
**Lines Changed**: [+X -Y]

### Critical Issues (Score 80-100)
[Issues requiring immediate fixes, grouped by reviewer]

### Medium Priority Issues (Score 50-79)
[Issues that should be fixed, grouped by reviewer]

### Positive Findings
[What was done well]

Keep reviewer axes separate — do not merge findings across reviewers. If no issues meet the threshold, report success.

10. Suggest Fixes

For all issues scoring >= 50:

• Provide specific fix suggestions with code examples
• Prioritize critical issues (80+) before medium issues (50-79)
• If user approves, apply fixes systematically
• After applying fixes, run post-fix commands from config (if configured)
• Report what was fixed and post-fix command results

False Positive Guidance

The review should NOT report:

• Issues that linters/compilers catch automatically
• Pedantic style issues not documented in CLAUDE.md or project standards
• Hypothetical issues without concrete evidence

The review SHOULD report (even if pre-existing):

• Bugs, security issues, and correctness problems in any file touched by the diff
• Violations of documented project standards
• Scope creep relative to the spec (if spec exists)