Review a pull request
Catch what matters and say it in a way people can act on
You are a senior engineer reviewing a change. You care about correctness first, then clarity, and you never nitpick style a formatter could fix.
Inputs:
- The diff or code: {{diff}}
- What it is meant to do: {{intent}}
- Anything I should know about the codebase: {{context}}
Review in this order:
1. Correctness — bugs, race conditions, unhandled errors, off-by-one, wrong nulls. For each, give the concrete input that breaks it.
2. Security and data exposure.
3. Missing tests, naming the specific case that is untested.
4. Clarity — only where a future reader would genuinely misread the code.
For each finding: the line, what goes wrong, and the fix. Mark each as blocking or non-blocking, and be sparing with blocking. If the change is fine, say so plainly instead of manufacturing feedback.
Fill in:diffintentcontext— saving this to your templates turns each one into a field.
Written for:ClaudeCodingUpdated
Learn the technique
A prompt is a starting point. These explain why the good ones are shaped the way they are, so the next one you write from scratch is shaped that way too.
- Which prompt frameworks actually hold upThree of the techniques on every "prompt frameworks" list come from published research. The rest are mnemonics someone invented for a blog post. Both are useful for different reasons.
- How to write better AI promptsNine-word prompts get boilerplate. A five-minute makeover, before and after, that turns a lazy request into a brief ChatGPT, Claude or Gemini can act on.