review

Review this code for [PERSPECTIVE]:

CONTEXT:
- Files changed: [list]
- Changes: [the diff or code]
- Full file context: [surrounding code]
- Project standards: [from CLAUDE.md, .editorconfig, etc.]

FOCUS: [What this perspective looks for - from table above]

OUTPUT: Return findings as a structured list, one per finding:

FINDING:
- severity: CRITICAL | HIGH | MEDIUM | LOW
- confidence: HIGH | MEDIUM | LOW (see reference.md for classification matrix)
- title: Brief title (max 40 chars, e.g., "Missing null check in auth service")
- location: Shortest unique path + line (e.g., "auth/service.ts:42-45")
- issue: One sentence describing what's wrong (e.g., "Query result accessed without null check, causing NoneType errors")
- fix: Actionable recommendation (e.g., "Add null guard: `if result is None: raise ServiceError()`")
- code_example: (Optional, include for CRITICAL and non-obvious HIGH severity)
  ```language
  // Before
  const data = result.data;

  // After
  if (!result) throw new Error('No result');
  const data = result.data;

Continue to **Phase 3: Synthesize & Present**.

---

### Phase 2 (Team Mode): Launch Review Team

> Requires `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` enabled in settings.

#### Setup

1. **Create team** — derive name from review target (e.g., `review-pr-123`, `review-feature-auth`, `review-staged`)
2. **Create one task per applicable review perspective** — all independent, no dependencies. Each task should describe the perspective focus, the files changed, diff context, and expected output format (structured FINDING format from the Standard perspective template).
3. **Spawn one reviewer per perspective**:

| Teammate | Perspective | subagent_type |
|----------|------------|---------------|
| `security-reviewer` | Security | `team:the-architect:review-security` |
| `simplification-reviewer` | Simplification | `team:the-architect:review-complexity` |
| `performance-reviewer` | Performance | `team:the-developer:optimize-performance` |
| `quality-reviewer` | Quality | `general-purpose` |
| `test-reviewer` | Testing | `team:the-tester:test-quality` |
| `concurrency-reviewer` | Concurrency | `team:the-developer:review-concurrency` |
| `dependency-reviewer` | Dependencies | `team:the-devops:review-dependency` |
| `compatibility-reviewer` | Compatibility | `team:the-architect:review-compatibility` |
| `accessibility-reviewer` | Accessibility | `team:the-designer:build-accessibility` |

> **Fallback**: If team plugin agents are unavailable, use `general-purpose` for all.

4. **Assign each task** to its corresponding reviewer.

**Reviewer prompt should include**: files changed with diff, full file context, project standards, expected output format (FINDING structure), and team protocol: check TaskList → mark in_progress/completed → send findings to lead → discover peers via team config → DM cross-perspective insights (e.g., "FYI: Found {issue} at {location} — relates to your review") → do NOT wait for peer responses.

#### Monitoring

Messages arrive automatically. If a reviewer is blocked: provide missing context via DM. After 3 retries, skip that perspective and note it.

#### Shutdown

After all reviewers report: verify via TaskList → send sequential `shutdown_request` to each → wait for approval → TeamDelete.

Continue to **Phase 3: Synthesize & Present**.

---

### Phase 3: Synthesize & Present

This phase is the same for both Standard and Team Mode.

**For Team Mode**, apply the deduplication algorithm before building the summary:

1. **Collect** all findings from review activities
2. **Deduplicate** overlapping findings (keep highest severity)
3. **Rank** by severity (Critical > High > Medium > Low) then confidence
4. **Group** by category for readability

Present in this format:

```markdown
## Code Review: [target]

**Verdict**: 🔴 REQUEST CHANGES | 🟡 APPROVE WITH COMMENTS | ✅ APPROVE

### Summary

| Category | Critical | High | Medium | Low |
|----------|----------|------|--------|-----|
| 🔐 Security | X | X | X | X |
| 🔧 Simplification | X | X | X | X |
| ⚡ Performance | X | X | X | X |
| 📝 Quality | X | X | X | X |
| 🧪 Testing | X | X | X | X |
| **Total** | X | X | X | X |

*🔴 Critical & High Findings (Must Address)*

| ID | Finding | Remediation |
|----|---------|-------------|
| C1 | Brief title *(file:line)* | Specific fix recommendation *(concise issue description)* |
| C2 | Brief title *(file:line)* | Specific fix recommendation *(concise issue description)* |
| H1 | Brief title *(file:line)* | Specific fix recommendation *(concise issue description)* |

#### Code Examples for Critical Fixes

**[C1] Title**
```language
// Before
old code

// After
new code

// Before
old code

// After
new code

**Table Column Guidelines:**
- **ID**: Severity letter + number (C1 = Critical #1, H2 = High #2, M1 = Medium #1, L1 = Low #1)
- **Finding**: Brief title + location in italics (e.g., `Missing null check *(auth/service.ts:42)*`)
- **Remediation**: Fix recommendation + issue context in italics (e.g., `Add null guard *(query result accessed without check)*`)

**Code Examples:**
- REQUIRED for all Critical findings (before/after style)
- Include for High findings when the fix is non-obvious
- Medium/Low findings use table-only format

### Phase 4: Next Steps

Use `AskUserQuestion` with options based on verdict:

**If REQUEST CHANGES:**
- "Address critical issues first"
- "Show me fixes for [specific issue]"
- "Explain [finding] in more detail"

**If APPROVE WITH COMMENTS:**
- "Apply suggested fixes"
- "Create follow-up issues for medium findings"
- "Proceed without changes"

**If APPROVE:**
- "Add to PR comments (if PR review)"
- "Done"

## Verdict Decision Matrix

| Critical | High | Decision |
|----------|------|----------|
| > 0 | Any | 🔴 REQUEST CHANGES |
| 0 | > 3 | 🔴 REQUEST CHANGES |
| 0 | 1-3 | 🟡 APPROVE WITH COMMENTS |
| 0 | 0 (Medium > 0) | 🟡 APPROVE WITH COMMENTS |
| 0 | 0 (Low only) | ✅ APPROVE |

## Important Notes

- **Parallel execution** - All review activities run simultaneously for speed
- **Intent-driven** - Describe what to review; the system routes to specialists
- **Actionable output** - Every finding must have a specific, implementable fix
- **Positive reinforcement** - Always highlight what's done well
- **Context matters** - Provide full file context, not just diffs
- **Team mode specifics** - Reviewers can coordinate via peer DMs to reduce duplicate findings; lead handles final dedup at synthesis
- **User-facing output** - Only the lead's synthesized output is visible to the user; do not forward raw reviewer messages