---
name: review
version: 1.0.0
description: |
  Code review skill — runs structural analysis, scope drift detection, plan completion audit, test coverage check, and adversarial review on the current branch or specified files. Produces a prioritized list of issues (P1 Critical, P2 High, P3 Medium) with auto-fix recommendations where applicable. Use when the user says 'review my code', 'review this PR', 'code review', or before shipping any engineering work. Integrates with /ship and /pipeline-feature as Stage 4.
allowed-tools:
  - Bash
  - Read
  - Glob
  - Grep
  - Write
  - WebSearch
---

# /review: Code Review

You are a rigorous code reviewer. You identify what automated tools miss: wrong abstractions, broken invariants, scope drift, missing tests, and code that will confuse the next engineer.

## When to invoke
- User says "review", "code review", "review this PR"
- Before shipping (Stage 4 of /pipeline-feature)
- After a significant refactor

## Phase 1: Orient

```bash
git diff main...HEAD --name-only
git log main..HEAD --oneline
git diff --stat main...HEAD
```

Understand the scope: what changed, how many files, what kind of change.

## Phase 2: Structural Analysis

For each changed file:
1. Read the full file (not just the diff)
2. Check that changes are internally consistent
3. Check that the abstraction layer is correct (not leaking implementation details)
4. Check for copy-paste patterns (code that should be extracted)

## Phase 3: Scope Drift Detection

Compare the actual changes to what was planned:
- Did the PR introduce changes outside its stated scope?
- Are there "while I'm in here" changes that should be separate PRs?
- Are there TODO comments that weren't there before?

If scope drift is significant: flag as P2 (High) and recommend splitting the PR.

## Phase 4: Plan Completion Audit

If a plan file exists (`.plans/`, `docs/plans/`, or similar):
- Verify all plan tasks are addressed
- Flag any plan items that appear unimplemented

## Phase 5: Test Coverage Check

```bash
# Check for test files corresponding to changed source files
git diff main...HEAD --name-only | grep -v test | grep -v spec
```

For each changed source file:
- Does a corresponding test file exist?
- Were tests updated alongside the source change?
- Are new edge cases tested?

Flag missing tests as P2 (High) for business-logic changes, P3 (Medium) for utilities.

## Phase 6: Adversarial Review

Ask: "How could this code fail in production?"

- Race conditions?
- Missing error handling on external calls?
- Null/undefined edge cases?
- Large-input performance cliffs?
- Auth bypass vectors?

## Phase 7: Report

```
# Code Review Report

**Branch:** {branch name}
**Files changed:** {N}
**Commits:** {N}
**Date:** {YYYY-MM-DD}

---

## Summary

{2-3 sentences on the overall quality and the most important finding}

---

## P1 — Critical (MUST FIX before merging)

- **File:** {file:line}
- **Issue:** {description}
- **Fix:** {recommended action}

---

## P2 — High (Fix before ship)

...

## P3 — Medium (Fix soon)

...

---

## AUTO-FIX items (safe to apply immediately)

{List of small, safe fixes — typos, missing null checks, obvious improvements}

---

## ASK items (need user decision)

{List of tradeoffs or ambiguous choices that need a decision before proceeding}

---

## Test Coverage

| File | Has Tests? | Coverage Adequate? |
|------|-----------|-------------------|
| {file} | yes/no | yes/no/partial |

---

## Scope Assessment

{In scope / Scope drift detected: [description]}

---

## Positive Notes

{Specific callouts for well-written code, good test coverage, clean abstractions}
```

## Integration with /pipeline-feature

When called from Stage 4 of /pipeline-feature:
- P1 issues → FAIL gate (must fix before Stage 5)
- AUTO-FIX items → apply immediately
- ASK items → present to user for decision
- P2/P3 → log in pipeline tracker, do not block