PR Review

Use this skill when reviewing a pull request in Cursor, Claude Code, or Codex.

Goal

Leave a review a staff engineer would stand behind: merge, request changes, or ask a precise question. Do not narrate the diff.

Inputs

• The full diff, not a file list
• The PR title and description
• Related tests, migrations, and API contract changes
• The intended user-facing behavior

If the diff is missing, stop and ask for git diff main...HEAD (or the repo's base branch).

Method

1. Restate the change in one sentence. If you cannot, the PR is not reviewable yet.
2. Check behavior first, then structure, then style.
3. Flag only defects that can cause a wrong merge, a security hole, data loss, a broken contract, or a missing test for a new branch.
4. Ignore formatting nits unless they hide a real bug.

Checklist

• Does the change match the stated intent?
• Are auth, authz, and tenant boundaries preserved?
• Are user inputs validated at the boundary (zod/schema), not trusted from the client?
• Do SQL/ORM queries stay parameterized? No string-built SQL.
• Are secrets, tokens, and PII kept out of logs and commits?
• Do migrations have a rollback story? Are they safe on a populated table?
• Are new branches covered by a test that would have failed before the fix?
• Does the UI verify the actual flow, not just a screenshot of the happy path?

Comment format

Write the GitHub/GitLab comment as:

## Summary
<one sentence>

## Verdict
Approve | Request changes | Comment

## Blocking
- <file:line> — <what breaks> — <what to do>

## Non-blocking
- <optional suggestion>

If there are no blocking issues, say so and approve. Do not invent work.

Anti-patterns

• "Looks good overall" with no evidence
• Rewriting the author's style
• Asking for a refactor unrelated to the risk in this diff
• Approving when tests were not run or are absent for the new path