Code Review Prompt Generator: Build One in 60 Seconds (2026)

TL;DR: A code review prompt generator is a template with six fields you fill in: language and version, framework, review focus, severity threshold, what you paste (diff or whole file), and output format. Fill them in, paste your code, and you get a review with file:line references and no nitpicks.

What is a code review prompt generator?

A code review prompt generator is a parameterised prompt template. You set six variables, paste your code, and the model returns a structured review instead of a polite summary of what your code already does. It is not a product you install. It is a block of text you keep and refill.

Here is the whole thing. Copy it, replace everything in square brackets, delete the options you do not want.

You are reviewing code for the senior engineer who wrote it. Be direct.

LANGUAGE: [Python 3.12 / TypeScript 5.6 / Java 21 / Go 1.23 / PostgreSQL 16]
FRAMEWORK & RUNTIME: [FastAPI + asyncpg, on AWS Lambda]
WHAT THIS CODE DOES: [one or two sentences]
WHAT CHANGED: [new file / bug fix for X / refactor of Y]
WHAT I AM WORRIED ABOUT: [the retry logic / a race under load / nothing specific]
REVIEW FOCUS, in order: [1. Correctness 2. Security 3. Performance 4. Readability]
SEVERITY THRESHOLD: Blocker and Major only. [or: include Minor]
SCOPE: [whole file / diff only / diff plus the rest of the file as context]
CONSTRAINTS: [Python 3.9 target, no new deps, this signature is public API]

OUTPUT - one entry per finding, nothing else:
  Severity: Blocker | Major | Minor
  Location: path/to/file.ext:NN
  Issue: one sentence
  Why it matters: the concrete failure, not the principle
  Fix: a code block I can paste

RULES:
- No nitpicks. Skip formatting, naming and style unless they cause a defect.
- Do not restate what the code does. I wrote it.
- If a finding is a guess, prefix it UNCERTAIN and say what you would check.
- If you find nothing at this severity, write "No findings." Never invent one.
- Finish with the three things you would check first given the whole repo.

CODE:
[paste here]

That is the generator. Everything below is about filling it in well.

Which fields actually change the output?

All six change it, but not equally. Language version and severity threshold do most of the work. Here is what each field buys you, and what happens when you skip it.

The free-text field people skip is "what I am worried about", and it is the one that changes the review most. A model given no suspicion spreads its attention evenly across the file. A model told "I think the retry loop can double-charge under a timeout" goes and checks that first, and either confirms it or tells you why it cannot happen. You are not biasing the review, you are giving it a starting point.

The severity threshold is the single highest-leverage line. A model asked to review code will find something, because returning nothing feels to it like failing the task. Capping the threshold and explicitly permitting an empty result is what turns the output from noise into signal.

What should you paste: the whole file, the diff, or the pull request?

Paste the diff plus enough surrounding code for the diff to make sense. Pasting the diff alone is the most common mistake and the reason so many AI reviews come back shallow.

A unified diff carries three lines of context. The model cannot see the function signature, the error handling above, or the caller below. So it reviews the lines rather than the change. It will tell you a variable could be a constant. It cannot tell you that the early return you added skips the cleanup in the finally block twenty lines further down, because that block is not on screen. The failure looks like a weak model. It is a starved prompt.

There is a ceiling. Dumping twelve files into one prompt does not buy you twelve files of attention, it buys you a review of the beginning and the end. The middle of a long context window gets the least careful treatment, and code review is exactly the task where careless treatment is worthless. One file per prompt, with the PR description repeated each time, is slower and better.

How do you control the output so the review is usable?

Three levers: a severity rubric, forced location references, and an explicit nitpick ban. Add all three and the output stops being an essay.

Define severity yourself. Left alone, the model invents its own scale and everything drifts to "medium". Paste this above your code:

SEVERITY RUBRIC - use these definitions, not your own:
- Blocker: data loss, security hole, crash on a normal input path, or a wrong
  result returned to a user.
- Major: fails on a realistic edge case, leaks a resource, or degrades badly
  under expected load.
- Minor: correct but fragile. Will bite someone in six months.
- Nit: style and taste. DO NOT REPORT unless I ask for nits.

State which line each finding matches, and why that line and not the one below.

That last sentence is the one that works. Forcing the model to justify a severity against the line below it stops everything from inflating to Blocker.

Force file:line references, and let it admit it does not know. Number your lines before pasting (cat -n file.py does it), then add:

Every line below is prefixed with its line number. Cite findings as
path/to/file.ext:NN. If you cannot determine the line, write UNKNOWN.
Never guess a number.

Without that escape hatch, a model unsure of a location produces a confident, plausible, wrong line number. That is a hallucination in the most annoying possible place: small enough to slip past you, and it costs two minutes every time.

Ask for JSON when something downstream reads the output. If the review feeds a script, a checklist, or a ticket template, skip prose entirely:

Return only JSON, no prose, matching this schema exactly:
{"findings":[{"severity":"blocker|major|minor","file":"","line":0,
"issue":"","why":"","fix":"","confidence":"high|medium|low"}],
"summary":"","checked_first":["","",""]}

The confidence field is what makes this worth doing: filter to high confidence automatically, read the rest yourself. Structured output is more reliable when you show the schema instead of describing it, which is covered in JSON prompts explained. Validate the response before trusting it. Well-formed JSON can still contain an invented line number.

What is the best code review prompt for each language?

The base generator works everywhere. These add the failure modes each language actually ships with, which is the part a generic prompt misses. Each one is self-contained: paste it, then paste your code underneath.

Treat these lists as a starting set, not a finished one. The fastest upgrade is to open the last twenty review comments your team left on real pull requests, find the three that keep recurring, and add them as checks. That is how a generic prompt becomes your team's prompt, and it takes about ten minutes.

Python code review prompt

Review this Python [3.12] code. Framework: [FastAPI / Django / none].
Blocker and Major only. No style or naming comments.
Per finding: Severity, file.py:NN, Issue, one-line why, Fix block.

Check for:
- Mutable default arguments and shared module-level mutable state
- Bare `except:` and broad excepts that swallow errors
- Resources opened without a context manager
- Blocking I/O inside async functions (requests, time.sleep, sync DB drivers)
- Naive datetimes where a timezone-aware one is required
- Mutating a list or dict while iterating it
- Public functions whose type hints contradict the body

CODE:

JavaScript and TypeScript code review prompt

Review this [TypeScript 5.6 / JavaScript ES2023] code.
Runtime: [Node 22 / browser / React 19].
Blocker and Major only. No formatting or naming comments.
Per finding: Severity, file.ts:NN, Issue, one-line why, Fix block.

Check for:
- Floating promises: async calls never awaited and never caught
- `any`, `as unknown as`, and `!` assertions hiding a real null case
- `==` coercion, and truthiness checks that swallow 0 and ""
- Mutation of props, state, or a caller's array or object
- fetch and JSON.parse with no failure branch
- React only: effect dependency arrays, stale closures, missing cleanup
- Non-exhaustive switch over a union type

CODE:

Java code review prompt

Review this Java [21] code. Framework: [Spring Boot 3 / plain / Android].
Blocker and Major only. Skip checkstyle-level comments entirely.
Per finding: Severity, File.java:NN, Issue, one-line why, Fix block.

Check for:
- equals/hashCode contract breaks, and objects mutated after use as a map key
- Resources not closed via try-with-resources
- Swallowed exceptions: empty catch, or catch that logs and continues
- Mutable static state, and non-thread-safe fields shared across requests
- Shared collections with no synchronisation and no concurrent type
- Autoboxing NPEs where a null Integer is unboxed into a primitive
- Optional misuse: Optional fields or parameters, .get() without isPresent
- Side effects inside stream lambdas
- String concatenation in loops on a hot path
- SimpleDateFormat and other non-thread-safe formatters held as fields

CODE:

Java gets the longest list here for a reason. Most of its sharpest defects are contractual rather than syntactic: the compiler is happy, the tests pass, and the bug arrives when a second thread shows up or when someone drops your object into a HashMap. Those are exactly the cases a generic "review my code" prompt sails straight past.

Go code review prompt

Review this Go [1.23] code.
Blocker and Major only. No naming or comment-style feedback.
Per finding: Severity, file.go:NN, Issue, one-line why, Fix block.

Check for:
- Errors ignored with `_`, or returned unwrapped so the call site is lost
- Missing `defer resp.Body.Close()` and other unclosed resources
- `defer` inside a loop where cleanup should happen per iteration
- Goroutines with no cancellation path, contexts never cancelled
- Concurrent map access without a mutex or sync.Map
- Writes to a nil map, and slice aliasing surprises after append
- Shadowed `err` in if-scoped statements hiding a later failure

CODE:

Rust code review prompt

Review this Rust [1.81] code. Async runtime: [tokio / none].
Blocker and Major only. No idiomatic rewrites with no behavioural difference.
Per finding: Severity, file.rs:NN, Issue, one-line why, Fix block.

Check for:
- unwrap() and expect() on paths that can fail in production
- Results discarded with `let _ =` where the error is meaningful
- Unnecessary clone() on a hot path
- Blocking calls inside an async fn, and a lock held across an .await
- `unsafe` blocks with no safety comment stating the invariant upheld
- Integer arithmetic assuming no overflow in release mode

CODE:

SQL code review prompt

Review this SQL for [PostgreSQL 16 / MySQL 8]. It runs [on every request /
nightly] against roughly [row count] rows.
Blocker and Major only.
Per finding: Severity, line NN, Issue, one-line why, Fixed query block.

Check for:
- Predicates that cannot use an index (leading wildcard, function on the
  column, implicit cast)
- Missing index for the WHERE, JOIN or ORDER BY columns used here
- Unbounded result sets with no LIMIT and no pagination
- Query shapes the caller will execute in a loop (N+1)
- UPDATE or DELETE with a WHERE that can match every row
- SQL assembled by string concatenation instead of parameters
- NULL semantics: NOT IN against a nullable subquery, `= NULL`

CODE:

If you want ready-made prompts for debugging and refactoring rather than review specifically, the 35-prompt code review and debugging pack covers those workflows. This page is the builder. That one is the pack.

What does AI code review catch, and what does it miss?

It is reliable on mechanical defects and unreliable on judgement. That distinction is the whole story, and pretending otherwise is how teams end up merging bad code with a green AI review attached to it.

Two honest caveats.

First, AI review does not replace a human on architecture, domain logic, or anything security-critical. It has no idea what your system is for. It cannot tell you that this endpoint should never have existed, that the permission check sits in the wrong layer, or that your refund path violates a rule your finance team wrote down in a document it has never read. Use it as the pass that clears the boring findings so your human reviewer spends their attention on design.

Second, it will occasionally produce a finding that is confidently and completely wrong. That is why the UNCERTAIN instruction is in the base template and why the JSON schema carries a confidence field. Treat every finding as a hypothesis until you have looked at the code yourself. A review you merge without reading is worse than no review, because it feels like diligence.

How do you run this without retyping it every time?

Retyping a forty-line template is how good prompt discipline dies in week two. Three ways to avoid it, in increasing order of setup effort.

Keep it as a saved template with the placeholders intact. Any snippet tool works. The requirement is that the six fields stay visible as blanks, so you fill them in rather than forgetting they exist and shipping a prompt still pointed at last month's language.

Turn the fields into variables. Language, framework and severity threshold change per repository but not per review, so they belong in a variable rather than in the body of the prompt. That is the difference between a template you edit and a template you fill. Reusable prompt variables for dev teams covers the pattern.

Call it from inside your editor. Prompt Architects runs an MCP server at https://mcp.prompt-architects.com/mcp that works with Claude Code, Cursor, Codex and Claude Desktop, so improve and refine are available as slash commands where the code already is. There is a free plan with a daily enhancement limit, and paid plans start at $4.99/month at the time of writing. Current pricing is on the pricing page. Built-in AI is included, so there is no separate API key to manage.

Whichever route you take, the point is the same: the generator is worth building once. After that it should be one keystroke away, with the six fields staring at you so you cannot skip them. If you want the underlying patterns rather than this specific template, the prompt engineering cheat sheet collects them in one page.

Start with the base block at the top, run it on the next thing you were about to push, then change one field and run it again. Most people find the severity threshold is the field they were missing.