pr-review

Pre-Review

Find and fix issues before publishing your PR — not after. Single-pass review using one capable model. No orchestration overhead, no agent swarm. Fast, cheap, thorough.

When to use

Reviewing code changes before publishing a PR Auditing existing code for bugs, security, or quality issues Finding and fixing issues in specific files or directories

When NOT to use

Running a coding agent to write new code → use coding-agent Checking GitHub CI status → use github Managing forks or rebasing branches → use fork-manager

Usage

/pr-review # Review changes on current branch vs main/master /pr-review src/api/ src/auth/ # Audit specific directories /pr-review **/*.ts # Audit files matching a pattern /pr-review --audit # Audit entire codebase with smart prioritization Two modes: ModeTriggerScopeFix thresholdDiffNo args, on branch with changesChanged files only>= 70AuditPaths, patterns, or --auditSpecified files or full codebase>= 80

Step 1: Detect Mode and Scope

No arguments provided: git diff main...HEAD --name-only 2>/dev/null || git diff master...HEAD --name-only If changes exist → Diff mode If no changes → inform user, stop Paths/patterns provided or --audit: Resolve to actual files (exclude node_modules, dist, build, vendor, .git, coverage) If > 50 files, ask user to narrow scope or confirm Audit mode

Step 2: Gather Context

Read project guidelines (quick scan, don't overthink): # Check for project conventions cat CLAUDE.md .claude/settings.json CONTRIBUTING.md 2>/dev/null | head -100 cat .eslintrc* .prettierrc* biome.json tsconfig.json 2>/dev/null | head -50 cat package.json 2>/dev/null | head -20 # tech stack Get the diff or file contents: # Diff mode git diff main...HEAD # or master # Audit mode cat <files> # read target files

Step 3: Review (Single Pass)

Analyze all code in one pass. Cover these areas in priority order: 1. Correctness (highest priority) Logic errors, edge cases, null/undefined handling Off-by-one, pagination boundaries, numeric precision Async/await mistakes, race conditions, resource leaks Data consistency, idempotency 2. Security Injection vulnerabilities (SQL, XSS, command, path traversal) Auth/authz gaps, IDOR risks, exposed secrets Unvalidated input reaching sensitive operations Logging sensitive data, insecure defaults 3. Reliability Error handling gaps, silent failures, swallowed exceptions Missing timeouts, retries without backoff Unbounded operations on user-controlled data 4. Performance N+1 queries, unnecessary loops, memory bloat Missing pagination, inefficient algorithms Blocking operations in async context 5. Quality (lowest priority — skip if trivial) Missing tests for new functionality Dead code, duplicated logic Stale comments, unclear naming Style issues only if they violate project guidelines

Step 4: Score and Classify

For each issue found, assign: ScoreMeaningAction90-100Critical bug or vulnerabilityMust fix70-89Real issue, will cause problemsShould fix50-69Code smell, needs human judgmentReport only< 50Minor, likely false positiveDiscard Discard thresholds: Diff mode: discard below 50 Audit mode: discard below 40 Classify each issue: blocker — security, data corruption, crash risk important — likely bug, perf regression, missing validation minor — edge case, maintainability, style

Step 5: Auto-Fix

Apply fixes directly for issues meeting the threshold: Diff mode: fix issues scoring >= 70 Audit mode: fix issues scoring >= 80 For each fix: read file → apply edit → verify surrounding code preserved. Never auto-fix: Issues requiring architectural changes Ambiguous fixes with multiple valid approaches Issues in test files (report only) After fixing, if any files were modified: git diff --stat # show what changed

Step 6: Report

• Format:
• ## Pre-Review Complete
• **Risk:** Low / Medium / High
• **Verdict:** ✅ Clean | ⚠️ Issues found | 🔴 Blockers
• ### 🔴 Blockers (must fix)
• 1. **file:line** — Description
• - Impact: what goes wrong
• - Fix: applied ✅ | manual required (reason)
• ### ⚠️ Important (should fix)
• 1. **file:line** — Description (score: XX)
• - Fix: applied ✅ | suggestion
• ### 💡 Minor
• 1. **file:line** — Description
• ### Tests to Add
• description of test
• ### Files Modified: N
• path/to/file.ts
• If zero issues found: ## Pre-Review Complete — ✅ Clean. No issues found.

Guidelines

DO: Fix issues directly, not just report them Match existing code patterns and style Be specific: file, line, concrete fix Prioritize impact over thoroughness DON'T: Fix pre-existing issues in diff mode — only what changed Bikeshed on style unless it violates project guidelines Report what a linter or type checker would catch (assume CI handles these) Make architectural changes or large refactors Spend tokens on obvious non-issues

False Positives to Avoid

Pre-existing code not touched by the current change (diff mode) Intentional patterns that look unusual but are correct Issues a type checker or linter would flag Style opinions not grounded in project guidelines General nitpicks a senior engineer would skip