ClawHub

pr-review

Automation

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).

Install

openclaw skills install 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 threshold
DiffNo args, on branch with changesChanged files only>= 70
AuditPaths, patterns, or --auditSpecified files or full codebase>= 80

Instructions

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:

ScoreMeaningAction
90-100Critical bug or vulnerabilityMust fix
70-89Real issue, will cause problemsShould fix
50-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
More in Automation