Review

---
description: Parallel code review with specialized agents for code changes
argument-hint: [scope] — optional, defaults to unstaged changes (git diff)
allowed-tools:
  - Read
  - Glob
  - Grep
  - Task
  - Bash(git diff*)
  - Bash(git show*)
  - Bash(git log*)
  - EnterPlanMode
  - ExitPlanMode
  - Edit
  - Write
model: inherit
context: inherit
hooks: {}
user-invocable: true
---

# Review

Orchestrated code review that launches 5 specialized agents in parallel.

## Input

- **$ARGUMENTS** — Review scope (optional)
  - Empty/omitted: unstaged changes (`git diff`)
  - `staged`: staged changes (`git diff --cached`)
  - `HEAD`: last commit (`git show HEAD`)
  - `<commit>`: specific commit
  - `<file1> <file2>...`: specific files
  - `<branch>`: changes on branch vs main

## Agents

| Agent | Focus |
|-------|-------|
| `orc:code-reviewer` | CLAUDE.md compliance, bugs, quality |
| `orc:silent-failure-hunter` | Error handling, silent failures |
| `orc:test-analyzer` | Test coverage, gaps, quality |
| `orc:type-design-analyzer` | Type invariants, encapsulation |
| `orc:frontend-verifier` | UI verification via browser automation |

## Process

### Step 1: Enter Plan Mode

Use `EnterPlanMode` tool to enter planning mode. The review findings will form the plan for fixes.

### Step 2: Determine Review Scope

Parse `$ARGUMENTS` to determine what to review:

```
if $ARGUMENTS is empty:
  scope = "unstaged changes"
  diff_cmd = "git diff"
elif $ARGUMENTS == "staged":
  scope = "staged changes"
  diff_cmd = "git diff --cached"
elif $ARGUMENTS == "HEAD":
  scope = "last commit"
  diff_cmd = "git show HEAD"
elif $ARGUMENTS matches commit hash:
  scope = "commit $ARGUMENTS"
  diff_cmd = "git show $ARGUMENTS"
else:
  scope = "$ARGUMENTS"
  diff_cmd = "git diff -- $ARGUMENTS" (or read files directly)
```

Run the diff command to get the changes to review.

### Step 3: Launch 5 Parallel Review Agents

Launch ALL agents simultaneously using Task tool with `subagent_type="orc:<agent>"`.

**Critical:** Send a SINGLE message with 5 Task tool calls to run them in parallel.

```
<Task subagent_type="orc:code-reviewer" description="Code review: guidelines">
Review scope: $scope

$diff_output

Review these changes against project guidelines (CLAUDE.md).
Focus on: compliance, bugs, code quality.
Report issues with confidence ≥80 only.
</Task>

<Task subagent_type="orc:silent-failure-hunter" description="Code review: error handling">
Review scope: $scope

$diff_output

Audit error handling in these changes.
Focus on: silent failures, empty catches, poor feedback.
Flag CRITICAL/HIGH/MEDIUM severity issues.
</Task>

<Task subagent_type="orc:test-analyzer" description="Code review: test coverage">
Review scope: $scope

$diff_output

Analyze test coverage for these changes.
Focus on: critical gaps, edge cases, test quality.
Rate gaps 1-10 (10 = must have).
</Task>

<Task subagent_type="orc:type-design-analyzer" description="Code review: type design">
Review scope: $scope

$diff_output

Evaluate type designs in these changes.
Focus on: invariants, encapsulation, enforcement.
Rate each dimension 1-10.
</Task>

<Task subagent_type="orc:frontend-verifier" description="Code review: UI verification">
Review scope: $scope

$diff_output

Verify the frontend still works correctly after these changes.
IMPORTANT: Backend API changes can break frontend even if no frontend files changed.

For backend changes: Test that frontends consuming these APIs still work.
For frontend changes: Test rendering, interactions, visual regressions.

Always:
1. Start the relevant services (backend + frontend)
2. Test key user flows end-to-end
3. Capture screenshots at each major step
4. Report any errors, broken flows, or unexpected behavior
</Task>

```

### Step 4: Collect and Synthesize Results

Wait for all 5 agents to complete. Synthesize findings into the plan file.

### Step 5: Exit Plan Mode

Use `ExitPlanMode` tool to present the review findings as a plan for user approval.

The plan should list all issues found, prioritized by severity, with specific file paths and line numbers.

### Step 6: Implement Fixes

After user approves the plan, implement the fixes:
1. Address **Critical Issues** first (must fix)
2. Address **Important Issues** (should fix)
3. Skip suggestions unless user requests them

For each fix:
- Read the file
- Make the specific change
- Verify the fix doesn't break anything

## Plan Format (written to plan file)

```markdown
# Code Review: $scope

## Summary

| Agent | Status | Issues |
|-------|--------|--------|
| code-reviewer | ✓/✗ | N critical, M important |
| silent-failure-hunter | ✓/✗ | N critical, M high |
| test-analyzer | ✓/✗ | N critical gaps |
| type-design-analyzer | ✓/✗ | N concerns |
| frontend-verifier | ✓/✗ | N UI issues |

## Critical Issues (will fix)

For each issue:
- [ ] **File**: `path/to/file.ts:123`
- **Issue**: Description
- **Fix**: Specific change to make

## Important Issues (will fix)

[Same format as critical]

## Suggestions (optional, user decides)

[Lower priority items - won't fix unless approved]

## Positive Findings

[What's done well across agents]

---
Total: N issues to fix, M suggestions available.
```

## Execution Rules

1. **Enter plan mode first** — use EnterPlanMode before starting
2. **Always run all 5 agents** — don't skip any
3. **Run in parallel** — single message with 5 Task calls
4. **Include full diff** — each agent needs the context
5. **Synthesize results** — don't just concatenate outputs
6. **Prioritize by severity** — critical first, suggestions last
7. **Exit plan mode** — present findings for user approval
8. **Implement fixes** — after approval, fix critical and important issues

## CRITICAL: Never Skip Frontend Verification

**NEVER skip frontend-verifier based on file types in the diff.**

Backend and frontend are linked systems. Backend API changes (routes, middleware, state management, auth) can and do break frontend functionality even when no frontend files are modified. Examples:
- API response shape changes → frontend parsing fails
- Auth middleware changes → frontend auth flow breaks
- State management changes → frontend data loading fails
- Route parameter changes → frontend API calls fail

**The frontend-verifier MUST run for:**
- Any backend API changes (routes, controllers, middleware)
- Any auth/session changes
- Any database schema changes
- Any state management changes
- ANY change that could affect API contracts

**Only skip frontend-verifier if:**
- User explicitly passes `--no-ui` flag
- Changes are purely documentation (README, comments only)
- Changes are purely test files with no implementation changes
- Changes are purely CI/CD configuration

When in doubt, RUN THE FRONTEND VERIFIER.

## Skip Conditions

Skip specific agents only if **explicitly requested by user**:
- `--no-tests`: skip test-analyzer
- `--no-types`: skip type-design-analyzer
- `--no-ui`: skip frontend-verifier (user must explicitly request this)

**Do NOT skip agents based on your own judgment about file types.** The user knows their system better than you do.

## Examples

```bash
# Review unstaged changes (default)
/review

# Review staged changes
/review staged

# Review last commit
/review HEAD

# Review specific files
/review src/auth.ts src/login.tsx

# Review branch changes
/review feature-branch
```