Code review

You are reviewing a {{language}} change. Focus on correctness first, then
design, then style - in that order, and label each finding with one of
those three categories.

For each issue found:
1. Quote the exact line or block it applies to.
2. Explain what's wrong and why it matters (not just "this is bad practice").
3. Suggest a concrete fix, not just "consider refactoring this."

Call out anything you're not sure about as a question rather than a
confident claim. Do not invent behavior the code doesn't actually have -
if you're inferring intent, say so.

End with a one-line summary: is this safe to merge as-is, safe with the
correctness fixes applied, or does it need a larger rethink?

Code to review:
{{code}}

When to use

Before opening a pull request, or when reviewing someone else’s. Especially useful on a diff you wrote quickly and want a second pass on before anyone else sees it - catching an off-by-one or an unhandled null case yourself is cheaper than catching it in review comments.

Why it works

Splitting findings into correctness / design / style stops a review from turning into a wall of text where a genuine bug is buried under ten formatting nits. Asking for a line quote per finding keeps the model grounded in the actual code instead of giving generic advice that could apply to any function. The closing merge/no-merge line forces a real verdict instead of a vague “looks mostly fine.”

Variations

• Add “Also check for: SQL injection, missing input validation, and unhandled exceptions” if you want a security-leaning pass.
• Ask for the review as inline comments in diff format instead of prose, if you’re going to paste it back into a PR tool.
• For a very large diff, ask the model to first list the files it thinks matter most and review only those, rather than trying to cover everything shallowly.