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

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

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

Phase 2: Route

Classify changed files and select applicable dimensions:

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

Phase 3: Review

For each applicable dimension, analyze the diff using the loaded methodology:

1. Code review — scan every changed file for guideline violations and bugs.

Apply confidence scoring (0-100). Only report issues >= 80.

1. Test analysis — map test coverage to changed code paths. Rate gaps 1-10.

Only report gaps >= 5.

1. Error handling — examine every error handler in the diff for silent failures.

Classify CRITICAL/HIGH/MEDIUM.

1. Type design — evaluate new or modified types on 4 dimensions (encapsulation,

invariant expression, usefulness, enforcement). Rate each 1-10.

1. Comment quality — verify accuracy, assess long-term value, flag comment rot.

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 mapping across dimensions:

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.

## Strengths
- What's well-done in this changeset.

## Recommended Action
1. Fix critical issues
2. Address important issues
3. Consider suggestions
4. Re-run review after fixes

If no issues are found at any severity level, confirm the code meets standards with a brief summary of what was reviewed and which dimensions were applied.

Aspect Selection

Users can request specific dimensions instead of running all:

When a specific aspect is requested, load only that reference file and skip routing.

Error Handling

Calibration Rules

1. Precision over recall. A false positive erodes trust in the review. Only report

issues at >= 80 confidence (code review) or >= 5 criticality (tests). Silence is better than noise.

1. File:line references are mandatory. Every finding must include a specific location.

Vague findings ("consider improving error handling") are not actionable.

1. Project rules override general rules. If CLAUDE.md says "use arrow functions",

do not flag arrow functions even if conventional style prefers function declarations.

1. Deduplication is mandatory. If two dimensions flag the same issue, merge them.

Never report the same problem twice.

1. Acknowledge strengths. A review that only lists problems is demoralizing. Note

what's done well, even briefly.

1. Code-refiner handles simplification. This skill reviews and reports. It does not

refactor or simplify — that's the code-refiner skill's job. Keep the roles separate.

Rationalizations

Red Flags

• Approving without reading every changed file in full (not just diff hunks)
• No file:line references in findings — vague feedback is not actionable
• Skipping a review dimension because "it looks fine"
• Reporting only style issues while ignoring logic, security, or architecture
• Reviewing generated code (migrations, protobuf stubs) with the same rigor as hand-written code
• Merging findings from different dimensions without deduplication

Verification

• Every changed file read in full, not just diff hunks
• Each review dimension scored: correctness, security, performance, readability, architecture
• Every finding includes a file:line reference
• At least one actionable finding per 100 lines changed, or explicit "no issues found" with justification
• Review summary includes risk level (LOW/MEDIUM/HIGH/CRITICAL) and blocking vs. non-blocking classification
• Strengths acknowledged — review is not 100% negative