/pr-review

name: pr-review
description: 'Diff-based PR review across code quality, test coverage, silent failures, type design, and comment quality with severity-ranked findings. Triggers on: "review my PR", "review this code", "check my changes", "audit this PR", "code review". NOT for pre-landing gate, use pre-landing-review.'
metadata:
  version: 1.2.0
  category: review
  tags: [code-review, pull-request, quality, diff-analysis]
  difficulty: intermediate
  phase: review

PR Review

Diff-based code review across five dimensions. Reads the changed files, selects applicable review methodologies, and produces an aggregated report with severity-ranked findings.

> **Native alternative:** Claude Code's `/ultrareview` runs a lightweight native bug-focused review (three free per month on Pro/Max plans at Opus 4.7's launch). Use this skill for five-dimension severity-ranked analysis (code quality + tests + error handling + types + comments) with file:line references; use `/ultrareview` for a quick bug-hunting pass on a diff.

Reference Files

| File | Contents | Load When | | ------------------------------- | ------------------------------------------------------- | ------------------------------- | | `references/code-review.md` | Guideline compliance, bug detection, confidence scoring | Always | | `references/test-analysis.md` | Behavioral test coverage, criticality rating | Test files changed | | `references/error-handling.md` | Silent failure patterns, catch block analysis | Error handling changed | | `references/type-design.md` | Invariant analysis, 4-dimension rating rubric | Type definitions added/modified | | `references/comment-quality.md` | Comment accuracy, long-term value, rot detection | Comments/docstrings added |

---

Workflow

Phase 1: Scope

1. Determine the review target:

• Default: `git diff` (unstaged changes)
• If user specifies a PR: `git diff main...HEAD` or `gh pr diff <number>`
• If user specifies files: review those files directly

2. List all changed files with `git diff --name-only` 3. Read the project's CLAUDE.md (if present) for project-specific rules

Phase 2: Route

Classify changed files and select applicable dimensions:

| Condition | Dimension | Reference to Load | | ---------------------------------------------------------------------------- | --------------- | ------------------------------- | | Always | Code review | `references/code-review.md` | | Files matching `*test*`, `*spec*`, `*_test.*`, `test_*` | Test analysis | `references/test-analysis.md` | | Files containing try/catch, except, .catch, Result, error callbacks | Error handling | `references/error-handling.md` | | Files containing class, interface, type, struct, enum, dataclass definitions | Type design | `references/type-design.md` | | Files with new/modified docstrings, JSDoc, or block comments | Comment quality | `references/comment-quality.md` |

Load only the reference files that apply. Skip dimensions with no matching files.

Phase 3: Review

Review the changed behavior and affected contracts using the applicable methodologies:

1. **Code review** — report demonstrated bugs and explicit rule violations at confidence >= 80. 2. **Test analysis** — identify plausible consumer-visible regressions that required behavior does not cover. 3. **Error handling** — trace failures and their caller-visible consequences. 4. **Type design** — assess current invariants and actual consumers; speculative extensibility is not a defect. 5. **Comment quality** — report misleading contracts that affect correct use; ordinary polish is optional.

Read enough surrounding implementation and call sites to prove each scenario. Review changed source rather than generated copies. On fixes, review the changed code and affected interactions; repeat a broader review only when a changed contract or base invalidates the earlier assessment.

Phase 4: Aggregate

Merge all findings into a single report, deduplicated and severity-ranked.

**Deduplication rules:**

• If two dimensions flag the same file:line, keep the higher-severity finding
• If code-review and error-handling both flag an empty catch block, merge into one

finding with the error-handling severity (it's the specialist)

**Severity is impact, not confidence or a design score.**

| Severity | Evidence and consequence | | --- | --- | | Critical | Demonstrated severe security, data-loss, availability or equivalent consumer risk; blocks merge. | | Important | Concrete regression, broken contract, required behavior gap or evidenced maintainability defect; blocks until resolved or an authorized decision addresses it. | | Suggestion | Optional polish or future capability; non-blocking and omitted unless useful or requested. |

Use confidence to filter uncertain claims, not to promote a certain nit into a Critical finding. Respect repository-specific severity labels and provider-required review policy.

---

Output Format

# PR Review Summary

**Scope:** [X files changed, Y dimensions applied]
**Dimensions:** [list of active dimensions]

## Critical Issues (must fix before merge)
- **[dimension]** `file:line` — Description. Fix suggestion.

## Important Issues (should fix)
- **[dimension]** `file:line` — Description. Fix suggestion.

## Suggestions (consider)
- **[dimension]** `file:line` — Description.

## Recommended Action
1. Resolve demonstrated blocking issues, batching fixes by bug class.
2. Re-review changed code and affected interactions only.
3. Leave optional suggestions non-blocking; do not expand the PR