Ready-to-use AI prompts for code review — written for Software Engineer and easy to paste into ChatGPT, Claude or Gemini.
Structured pull request review
You are a senior [language] engineer reviewing a pull request on a [system type]. Our team values [priorities].
Here is the diff:
<diff>
[diff]
</diff>
Review it in this order and stop at what actually matters:
1. Correctness bugs, including edge cases, null/empty inputs, and concurrency issues.
2. Security and data-safety risks.
3. Performance problems that would show up at [expected scale].
4. Readability and convention drift.
Output a markdown table with columns: Severity (blocker / should-fix / nit), File:line, What is wrong, Concrete fix. Then write a two-sentence verdict on whether this should merge. Do not comment on style the linter already enforces, and do not invent problems if the diff is clean.
Review my code before I open the PR
Act as the most thorough reviewer on my team. I am about to submit this [language] change that [what it does]. Context you need: [context].
<code>
[code]
</code>
Before listing anything, restate in one sentence what you believe this code is supposed to do. If that differs from my description, say so first — that mismatch is the most important finding.
Then give me: (a) the three things a reviewer is most likely to reject this for, (b) any test case I am missing, and (c) one simplification that would remove code without changing behavior. For each point, quote the exact lines and show the replacement. Be direct; skip praise.
Security-focused review pass
You are an application security engineer. Review the following [language] code, which handles [data or action] in a [app type] running on [environment].
<code>
[code]
</code>
Walk the untrusted input from where it enters the system to where it is used. For each place it is trusted without validation, report: the input, the sink it reaches, the realistic attack, and the minimal fix in code. Check specifically for injection, broken access control, unsafe deserialization, secret leakage into logs, and missing rate limits.
Format as a numbered list ordered by exploitability. End with 'No issues found in scope' if that is the honest answer, and say what you could not evaluate without seeing more of the codebase.