| 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
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:
- Issue references in the revision description (LINEAR-123, #123, GH-45, etc.)
- A path the user passed as an argument
- A spec file under
docs/, specs/, or .scratch/ matching the bookmark name or feature
- If nothing found, ask the user where the spec is
- 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.mdCONTRIBUTING.mdCONTEXT.md, CONTEXT-MAP.md, per-directory CONTEXT.md filesdocs/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)
