The prompt template I use for every AI code review

Default "review this code" prompts produce stylistic noise: variable naming suggestions, brace placement preferences, "consider adding a comment here". Useful prompts narrow what counts as a finding. This is the template we use ourselves for code review across AI tools — same prompt for Claude, GPT-5, Gemini — with examples of what to add for specific languages.

The template

Review the code below.

Don't comment on:
- Style (naming, brace placement, comment density)
- Stylistic refactor opportunities you can't show are bugs
- Anything you'd flag as "consider doing X"

DO flag:
- Bugs (anything that wouldn't work as the author intended)
- Footguns (anything that works but invites future bugs — race conditions,
  silent type coercion, missing error handling on operations that fail)
- Missing tests (important behavior without coverage)
- Security issues (any handling of user input, secrets, or external data
  that could be exploited)

For each finding:
- Quote the line you're flagging (with line number if available).
- Say what's wrong in one sentence.
- Say what to do about it in one sentence.

Skip the rest of the code without comment.

The code:
```

<your code here>
```

The "skip the rest of the code without comment" line cuts the most noise. Without it, models pad reviews with "this looks good" filler that drowns the actual findings.

What to add per language

JavaScript / TypeScript:

Pay specific attention to:
- async/await misuse (missing awaits, swallowed promise rejections)
- type coercion bugs (== vs ===, falsy-value pitfalls)
- mutability through references that the caller didn't expect

Python:

Pay specific attention to:
- mutable default arguments
- variable scoping bugs (closures capturing loop variables)
- division behavior (// vs /)
- iterator exhaustion

Rust:

Pay specific attention to:
- borrow checker workarounds that subvert intent (unnecessary clones, unsafe blocks)
- lifetime annotations that don't reflect actual usage
- error handling that uses .unwrap() in places where Result propagation would be safer

SQL:

Pay specific attention to:
- N+1 query patterns disguised as application logic
- Missing or wrong indexes on WHERE/JOIN columns
- Implicit type conversions in WHERE clauses
- Locking behavior on long-running UPDATEs

A worked example

Code:

async function getUser(id: string) {
  const user = await db.users.findOne({ id });
  return { ...user, lastSeen: new Date() };
}

Default prompt ("review this") might say: "consider adding error handling, consider extracting the date into a constant."

The template prompt gets you: "Bug — the spread { ...user } will include a lastSeen field from the DB if one exists, which the second line overwrites; this is fine here but if the schema adds a field with lastSeen semantics elsewhere, the order-dependence becomes a footgun. Footgun — no handling for user being null (id not found); right now this returns { lastSeen: <date> } with no other fields, which the caller likely doesn't handle."

The template's restraint about style frees up budget for the actual issues.

When to NOT use this template

If you're learning a language and you want a tutor that DOES comment on style and pattern choices, this template is wrong for you. Use a different prompt that explicitly asks for teaching feedback. The template above is for code you're shipping.

Where this fits

If you keep one system prompt across models, you can paste this template into a per-task instruction set rather than retyping it. For coding-heavy work specifically, see Cursor vs Claude Code vs Windsurf — those tools embed similar code-review patterns directly in your editor.

More playbooks in Playbooks. Or try oran.chat free to run the same review prompt against multiple models on the same code.