Structured code review with a severity checklist

You are a senior [LANGUAGE] engineer doing a code review. Review the code below.

Context:
- What the code is supposed to do: [PURPOSE]
- Where it runs: [e.g. "public web API", "internal batch script"]
- Project conventions: [STYLE GUIDE, FRAMEWORK, VERSION]
- Focus areas, if any: [e.g. "security", "performance"]

Check the code against this list, in order:
1. Correctness: logic errors, edge cases (empty input, null, large values), off-by-one errors.
2. Security: input validation, injection, secrets in code, unsafe deserialization, permissions.
3. Error handling: failures that are swallowed, unclear error messages, missing cleanup.
4. Performance: unnecessary loops, repeated I/O, N+1 queries, memory growth.
5. Readability: naming, function length, duplicated code, missing comments where logic is non-obvious.
6. Tests: what is untested and which test cases you would add.

Output format:
- A table: # | Severity (blocker/major/minor/nit) | Line(s) | Issue | Suggested fix
- Then up to 3 code snippets showing the most important fixes.
- Then "What is good": 2-3 things worth keeping.

Rules: only report issues you can point to in the code. If something depends on code you cannot see, list it under "Questions for the author" instead of guessing.

Code:
```
[PASTE CODE OR DIFF]
```

Example (excerpt):
| # | Severity | Line(s) | Issue | Suggested fix |
| 1 | Blocker | 14 | SQL query built with string concatenation from user input | Use a parameterized query |
| 2 | Minor | 22-40 | Function does parsing and saving; hard to test | Split into parse() and save() |

Questions for the author: Is `user_id` already validated by the router?

When to use it

Use this prompt before opening a pull request, when reviewing a colleague’s change, or when you inherit unfamiliar code. It works as a first pass that catches common problems so that human reviewers can spend their time on design and intent. It is not a replacement for a human review on code that matters, but it reliably surfaces issues that are easy to miss when you are tired or in a hurry.

How to customize it

• [LANGUAGE] sets the expertise: “senior Python engineer”, “senior TypeScript engineer”.
• [PURPOSE] is essential. Without it, the model can only judge style, not whether the code does what it should.
• [WHERE IT RUNS] changes the priorities: a public API needs much stricter security than a one-off script.
• [CONVENTIONS] prevents suggestions that clash with your framework or style guide.
• [FOCUS AREAS] lets you narrow a long review, for example to security only.
• [PASTE CODE OR DIFF] can be a single file or a diff. Include the surrounding code if a function depends on it.

Why it works

A fixed checklist makes the review systematic: the model goes through each category instead of stopping after the first obvious problem. The severity column turns a wall of comments into a prioritized list, which is how experienced reviewers work.

The constraint “only report issues you can point to” and the separate “Questions for the author” section reduce invented problems about code the model cannot see. Asking for “What is good” keeps the review balanced and tells you what not to change. For more on working with coding assistants, see our guide on using AI coding assistants effectively.

Tips and variations

• Do not paste secrets, keys or private customer data. Replace them with placeholders first.
• For large changes, review one file or function at a time; quality drops when too much code is pasted at once.
• Ask a follow-up: “Write unit tests for findings 1 and 3” to confirm the bugs are real.
• Treat security findings as leads, not proof. Verify them yourself or with a dedicated scanner.
• Save your checklist as a reusable instruction in your assistant or IDE so every review uses the same standard.