---
name: pr-reviewer
description: Use when reviewing a pull request, staged changes, or a specific diff. Produces copy-paste-ready markdown code review with constructive criticism — problems, severity, and suggested fixes — formatted for GitHub PR comments.
---

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

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

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

4. **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.

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

```markdown
## 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