# Pr Review

> Find and fix code issues before publishing a PR. Single-pass review with auto-fix. Use when reviewing code changes before submission or auditing existing code for bugs/security. Don't use when running a coding agent to write code (use coding-agent) or checking GitHub CI status (use github).

- Skill: `modbender/pr-review` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add modbender/pr-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/modbender/pr-review/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: modbender (https://skillmd.com/u/modbender)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/modbender/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:

| Mode | Trigger | Scope | Fix threshold |
|------|---------|-------|---------------|
| **Diff** | No args, on branch with changes | Changed files only | >= 70 |
| **Audit** | Paths, patterns, or `--audit` | Specified files or full codebase | >= 80 |

## Instructions

### Step 1: Detect Mode and Scope

**No arguments provided:**
```bash
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):
```bash
# 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:
```bash
# 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:

| Score | Meaning | Action |
|-------|---------|--------|
| 90-100 | Critical bug or vulnerability | Must fix |
| 70-89 | Real issue, will cause problems | Should fix |
| 50-69 | Code smell, needs human judgment | Report only |
| < 50 | Minor, likely false positive | Discard |

**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:
```bash
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