Code review prompt template

"Review this code" gets you a polite list of twelve suggestions, half of them about variable names. The bug that will page someone at 3 a.m. is in there somewhere, ranked the same as a missing semicolon. A good code review prompt tells the model what kind of reviewer to be, where the code runs and what to ignore, so the important findings come first.

The prompt Promptay builds

Role: You are a senior TypeScript engineer doing a careful review before a production release.
Task: Review the function below, which merges two lists of user records, for bugs, unhandled edge cases and data loss.
Context: It runs in a Node.js service that syncs users from two sources about every 5 minutes. Lists can hold up to 50,000 records. Users are matched by email, and either source can have missing or differently cased emails.
Format: A numbered list of issues ranked by severity (critical, major, minor). For each issue: one sentence on the problem, one sentence on its impact, and a corrected snippet of only the lines that change.
Constraints: Focus on correctness, then performance. Skip formatting and naming unless it causes a bug. Do not rewrite the whole function. If the code is correct for a case, do not invent a problem.

Why this prompt works

• The runtime context finds the real bugs. Mentioning 50,000 records and mixed-case emails points the model at quadratic loops and case-sensitive matching, the two classic failures here.
• Severity ranking separates signal from noise. You can stop reading after the critical items if time is short.
• Small diffs, not rewrites. Asking only for the lines that change keeps fixes easy to verify and apply.
• Permission to find nothing. "Do not invent a problem" reduces the false positives models produce when they feel they must say something.

How to adapt it

Replace the language, the runtime and the scale with yours; those three details change the review more than anything else. For a security-sensitive change, add "check input validation, authorization and secrets handling first". For a pull request rather than a single function, paste the diff and ask for issues grouped by file. To review against your team's standards, include your checklist in the context.

Ideas to try next:

• "Review this SQL migration for locking problems on a large table"
• "Write unit tests for the edge cases you found in this function"
• "Explain this legacy Python module to a new team member before they change it"