# Pull request review

> Review a diff against the repository's own conventions, in the order a maintainer does.

- Skill: `vstorm-co/pull-request-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vstorm-co/pull-request-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vstorm-co/pull-request-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: vstorm-co (https://skillmd.com/u/vstorm-co)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vstorm-co/pull-request-review

---


# Reviewing a pull request

Read the surrounding code before the diff. Most real problems are in what the
change assumes, not in what it says.

## In this order

1. **Does it do what it claims** — and does the description match the diff?
2. **The failure paths** — errors, empty results, concurrency, partial writes.
3. **Tests** — does one fail without the fix? A test that passes on the old code
   tests nothing.
4. **Conventions** — the repository's, not your preferences.
5. **Blast radius** — what else calls this, and does the change hold for them?

## Say why, and how sure

Distinguish "this is a bug, here is the input that breaks it" from "I would have
done this differently". Both are worth saying; conflating them wastes the
author's time.

## Always sweep the siblings

If the change touches one of several similar call sites, check the others. The
same defect is usually in all of them.

## Never

Block on style a formatter should own, or approve a diff you did not understand
because the author is senior.