🎁 Get the FREE AI Skills Starter Guide β€” Subscribe β†’
BytesAgainBytesAgain
BytesAgain β€Ί Skills β€Ί pr-review
πŸ¦€ ClawHub

pr-review

by @glucksberg

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

Versionv2.0.1
Downloads2,063
Installs6
#legal#health
TERMINAL
clawhub install pr-review

πŸ“– About This Skill

name: pr-review description: 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). metadata: {"openclaw": {"requires": {"bins": ["git"]}}}

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: 

    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   # 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: 

    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

    • ⚑ When to Use

    TriggerAction
    - Auditing existing code for bugs, security, or quality issues
    - Finding and fixing issues in specific files or directories

    πŸ’‘ Examples

    /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 |