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

Security Scan

The skill's requests and runtime instructions are consistent with a pre-PR code review tool that reads the repository and may auto-edit files; nothing requested is out-of-scope for that purpose.

Purpose & Capability

The skill is named pr-review and its instructions implement a 'pre-review' workflow: running git diffs, reading project config (eslint, tsconfig, CLAUDE.md), analyzing files, and applying fixes. Requiring the git binary and reading repository files is proportionate to the stated purpose. Minor naming inconsistency: the docs and commands mostly refer to 'pre-review' while the skill name is 'pr-review', but this is likely cosmetic.

Instruction Scope

The SKILL.md explicitly instructs the agent to read repository files, run git diff/blame, analyze code, and perform in-place auto-fixes above configured confidence thresholds (>=70 for diff mode, >=80 for audit). Reading project configuration files (CLAUDE.md, .eslintrc*, package.json) is expected for guideline-aware review. The notable operational risk is that the skill will edit repository files automatically — users should expect and review changes (git diff) after running. There are no instructions to read system-wide files or environment secrets outside the repository.

Install Mechanism

This is an instruction-only skill with no install spec or code files that execute arbitrary downloads. That minimizes install-time risk; nothing is fetched from external URLs or written to disk by an installer.

Credentials

The skill declares no required environment variables, credentials, or config paths outside the repo. The files it reads (repo config and project files) are appropriate for a code-review tool. There are no requests for unrelated cloud or service credentials.

Persistence & Privilege

always:false (normal). The skill is allowed to run autonomously by default (platform default) and its instructions include making edits to repository files. Autonomous invocation combined with auto-edit behavior increases the practical blast radius: consider requiring explicit confirmation before allowing edits or running the skill on a disposable branch. The skill does not request persistent system-wide privileges or modify other skills.

Assessment

This skill is coherent for its stated purpose: it will read your repository (git diff, config files, source files) and apply automatic fixes above configured confidence thresholds. Things to consider before running: - Back up or commit your branch first (run on a feature branch) so you can review or revert changes. - Review the diffs after the run (git diff --stat and full diff) and run your tests before pushing. - Note the auto-fix behavior: Diff mode auto-fixes issues scoring >=70 and Audit mode >=80 — adjust your expectations accordingly. - If you don't want the agent to edit files without explicit approval, require confirmation or run the tool in a dry-run/report-only mode. - The skill is instruction-only (no external installers), reads only repo files, and requests no cloud credentials — there are no obvious indicators of secret exfiltration or out-of-scope access. - Minor naming inconsistency: documentation refers to 'pre-review' commands while the skill is named 'pr-review' — confirm command names when installing/invoking. If you want extra assurance, run it on a non-production copy of the repo first and inspect the changes before trusting it on critical branches.

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

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