PR Reviewer

Overview

Hostile but constructive code review of a diff or set of changed files. Assumes problems exist and hunts for them, then packages every finding as actionable, copy-paste-ready markdown suitable for posting directly into a GitHub PR review. Does not write a findings file — output goes to stdout only.

When to Use

• Reviewing a PR before approving or requesting changes
• Reviewing your own staged/committed changes before pushing
• Getting a second hostile eye on a specific set of files
• Generating a ready-to-paste review comment for a GitHub PR

Process

1. Identify the scope. Accept one of:

• Git diff: git diff main...HEAD (default if no argument given)
• Staged only: git diff --cached
• Specific files: paths passed as arguments
• PR number: fetch diff via gh pr diff <number>

1. Run through the review checklist (same categories as nitpicker) against the changed lines only. Do not flag issues in unchanged context lines.

1. For each finding, record:

• Severity (Critical / High / Medium / Low)
• File and line number
• What is wrong (one sentence, no hedging)
• Concrete trigger that reproduces the problem
• Suggested fix (code snippet when possible)

1. Emit the review to stdout in the output format below. Nothing else — no preamble, no summary prose.

Review Checklist

Apply to changed lines only. Skip categories with no relevant constructs in the diff.

• Correctness — logic errors, off-by-one, wrong operator, missed condition
• Edge cases — null/empty/zero/max, Unicode, duplicate calls, first/last element
• Error handling — swallowed errors, missing await, overbroad catch, no cleanup
• Security — injection, missing auth, secret exposure, trust boundary violations
• State & concurrency — races, TOCTOU, stale closures, missing synchronisation
• Data integrity — unvalidated input, partial writes, constraint violations
• Resource management — leaks, unbounded growth, missing timeouts
• Conventions — violates patterns established in surrounding unchanged code

Output Format

Emit a single markdown block, ready to paste into a GitHub PR comment. No wrapping text.

## Code Review

### Critical
<!-- omit section if empty -->

- **[short title]** — `path/to/file:line`
  [What is wrong — one sentence.]
  **Trigger:** [exact input or sequence]
  **Fix:** [minimal corrective action or code snippet]

### High
...

### Medium
...

### Low
...

---
_Review generated by pr-reviewer. Findings cover changed lines only._

If no findings: emit only:

## Code Review

No issues found in the changed lines.

Common Mistakes

• Do NOT report issues in unchanged context lines
• Do NOT omit the Trigger: — every finding must be reproducible
• Do NOT write findings to docs/audit/ or any file
• Do NOT include style opinions, naming preferences, or "I would do it differently"
• Do NOT manufacture issues to seem thorough — silence is correct when nothing is wrong
• Do NOT add a summary paragraph before or after the markdown block