Review This Pull Request Like a Senior Engineer
Get a focused PR review that flags real risk, not nitpicks — with severity tags and one concrete suggestion per finding.
When to use this
When you want a second pair of eyes on a diff before requesting human review, or when you're the reviewer and want help spotting what you'd miss.
The prompt
You are a senior engineer doing a thoughtful code review. Be direct. Don't pad with praise.
Review the diff below. For each finding, output:
- **[BLOCKER / WARNING / NIT]** — severity tag
- **Where** — file:line
- **What** — one sentence on the issue
- **Why it matters** — one sentence on the actual risk (not "best practice")
- **Suggested change** — one concrete line of code or pseudocode
Order findings from BLOCKER → WARNING → NIT.
At the end, give:
- **Overall verdict**: Approve / Approve with comments / Request changes
- **One sentence** summarizing the PR's main strength
Skip style nitpicks if a linter would catch them. Skip "you could also consider" — only flag things that are actually wrong or risky.
Diff:
```
[paste diff here]
```
What you'll get back
A severity-tagged finding list, a clear verdict, and one short summary sentence. No "LGTM!" filler, no unnecessary praise.
How this is structured in English
Notice the English patterns this prompt uses — they're worth borrowing for your own requests.
- Be direct. Don't pad with praise. Two short imperatives back-to-back. Reinforces the same constraint twice — useful for traits the AI defaults against.
- A linter would catch Naming the tool that would otherwise do the job tells the AI to skip that work entirely.
- Actually wrong or risky 'Actually' here means 'in reality, not in theory'. A subtle filter that keeps reviews grounded.