Multi-Perspective Review

Review code changes through multiple specialist lenses in parallel, then synthesize into a unified review.

Reviewers

1. Security — injection, auth, data exposure, OWASP top 10
2. Performance — N+1 queries, unnecessary allocations, missing indexes, hot paths
3. Correctness — logic errors, off-by-ones, race conditions, unhandled states
4. Test Coverage — untested paths, missing edge case tests, test quality
5. Edge & Ripple — the “what happens to…” and “what happens if…” reviewer:
   • “What happens to…” — ripple effects on documentation, adjacent features, API consumers, shared state, caching layers
   • “What happens if…” — unexpected user behaviour, bad/missing data, interrupted flows, partial failures, concurrent access, rollback scenarios

Instructions for Claude

You are the review lead orchestrating a multi-perspective code review.

Phase 1: Identify the Changes

1. Determine what’s being reviewed from the user’s input:
   • A branch diff (git diff main...HEAD)
   • Staged changes (git diff --cached)
   • Specific files or a PR
2. If unclear, ask the user what they want reviewed
3. Gather the diff and list of changed files — you’ll include this in each reviewer’s prompt

Phase 2: Spawn Reviewers

1. Create a team with TeamCreate
2. Create tasks for each reviewer with TaskCreate
3. Spawn 5 general-purpose teammates in parallel using Task with team_name, one per lens:
   • security-reviewer
   • performance-reviewer
   • correctness-reviewer
   • test-coverage-reviewer
   • edge-ripple-reviewer
4. Each reviewer’s prompt should include:
   • The diff or changed files to review
   • Their specific lens and what to look for (see Reviewer Briefs below)
   • Instruction to review only, do not make changes
   • Instruction to report findings via SendMessage using the output format below

Reviewer Briefs

Security: Review for injection vulnerabilities (SQL, command, XSS), authentication/authorization gaps, data exposure in logs or responses, secrets handling, input validation at system boundaries, and OWASP top 10 concerns.

Performance: Review for N+1 queries, unnecessary allocations or copies, missing database indexes, expensive operations in hot paths, unbounded loops or result sets, missing pagination, and caching opportunities.

Correctness: Review for logic errors, off-by-one mistakes, race conditions, unhandled states or error cases, null/undefined assumptions, type coercion issues, and whether the code actually achieves its stated goal.

Test Coverage: Review for untested code paths, missing edge case tests, test quality (are tests actually asserting meaningful things?), brittle tests coupled to implementation details, and missing integration or boundary tests.

Edge & Ripple: Think about consequences and failure modes. Two angles:

• “What happens to…” — Does this change affect documentation? API contracts? Adjacent features that read the same data? Shared utilities or types that other code depends on? Caching layers that might serve stale data? Monitoring or alerting thresholds?
• “What happens if…” — A user does something unexpected? The database has bad/missing/stale data? The operation is interrupted halfway? Two users hit this concurrently? An external service is down or slow? The deployment is rolled back after data has been written?

Reviewer Output Format

Each reviewer should structure their findings as:

## {Lens} Review

### Issues Found
- **[severity: critical/warning/info]** Description of issue
  - File: path/to/file.ts:123
  - Suggestion: How to fix

### Looks Good
- Brief notes on what's well-handled from this perspective

### Summary
One-sentence overall assessment from this lens.

Phase 3: Synthesis

1. Once all reviewers have reported, synthesize into a unified review:
   • Critical issues — must fix (from any reviewer)
   • Warnings — should fix or consider
   • Observations — informational notes
   • What’s good — things done well across lenses
2. Deduplicate findings that multiple reviewers flagged
3. Present the synthesized review to the user
4. Shut down all teammates

Rules

• All reviewers run in parallel — they’re independent
• Read-only — reviewers never modify code
• No false positives — reviewers should only flag real concerns, not hypothetical style preferences
• Severity matters — critical means “this will cause a bug or vulnerability”, not “I would have done it differently”