← Ship-It Skills for Claude Code
This is the complete file, exactly as it ships in the pack.
---
name: pr-review
description: Use when asked to review a diff, branch, or pull request. Gives a prioritized, evidence-based review (blockers, risks, nits) instead of a wall of style comments.
---
# PR review
Goal: find the problems that would hurt in production, explain them with evidence, and
keep noise low.
## Gather context
1. Get the diff: `git diff <base>...HEAD` (default base: `main`, fall back to `master`), or
`gh pr diff <number>` if the GitHub CLI is available.
2. Read the PR description / commit messages to learn the intent.
3. For every changed function, open the full file, not just the hunk. Look at callers of any
changed signature (`rg -n "functionName\("`).
4. Check whether tests changed alongside the code.
## Review checklist (in priority order)
1. **Correctness:** does the code do what the description says? Off-by-one, null/undefined,
empty collections, error paths, timezones, integer/float, async ordering, retries.
2. **Data safety:** migrations reversible? Destructive operations guarded? Transactions where
needed? Idempotent handlers for webhooks/queues?
3. **Security:** input validation, authz on new endpoints, secrets in code or logs, injection
(SQL, shell, HTML), SSRF on user-supplied URLs, unsafe deserialization.
4. **Contracts:** public API, DB schema, config, env vars, CLI flags — are breaking changes
intentional and documented?
5. **Tests:** is the new behavior covered? Would the tests fail if the fix were reverted?
6. **Operability:** logging on failure paths, useful error messages, feature flags, metrics.
7. **Readability:** naming, dead code, duplicated logic. Keep these as nits.
## Output format
```
## Summary
<2-3 sentences: what the PR does and overall verdict: approve / approve with nits / request changes>
## Blockers (must fix)
- file:line — problem — why it matters — suggested fix
## Risks / questions
- ...
## Nits (optional)
- ...
## What I checked
- <commands run, files read, tests executed>
```
## Rules
- Every blocker needs evidence: a line reference and a concrete failing scenario.
- Do not invent problems to fill a section. "None found" is a valid answer.
- If you can run the tests locally, do it and report the result.
- Do not push, merge, approve on the platform, or post comments unless explicitly asked.