Code Review Prompt Template

“Review this code” is the single least useful code review prompt you can write, and it’s also the most common one. A model asked to review everything at once produces surface-level observations spread thin across every category — security, readability, performance — instead of the kind of depth that’s actually useful in a real pull request. The fix isn’t a smarter model; it’s a more scoped prompt.

This template briefs the model as a specialized reviewer with a defined scope, current-versus-expected context, and a required output format — line number, severity, and a specific fix for every finding — rather than a generalist scanning everything simultaneously.

The core template

Act as a senior [language/framework] engineer reviewing this code specifically for [scope: security | performance | readability | architecture -- pick one or list several].

Language/framework/runtime: [e.g., Python 3.12, FastAPI, PostgreSQL]
Key dependencies relevant to this review: [only what's relevant -- not your full dependency list]

Code to review:
[paste only the relevant file(s) or function(s) -- not the whole repository]

Current behavior: [what the code does today]
Expected behavior: [what it should do, if correctness is part of the scope]

Team conventions: [describe key style/architecture rules, or "standard [language] conventions" if none are unusual]

For each issue found, report: the line number, a severity (critical / major / minor), and a specific suggested fix. Stay within the scope above -- do not report findings outside it.

Why each slot matters

• Scope. The single highest-leverage slot in this template. A model told to review “for authentication and authorization gaps” produces findings you can act on; a model told to just “review this” produces a scattered list touching everything lightly and nothing deeply.
• Language/framework/runtime and relevant dependencies. Generic advice ignores framework-specific idioms and version-specific gotchas. Naming the actual stack lets the model apply conventions specific to it rather than defaulting to language-agnostic generalities.
• Only the relevant code, not the whole repository. Pasting an entire codebase dilutes the model’s attention across mostly-irrelevant context and makes findings harder to act on. Scope the code to what the review actually needs to see.
• Current versus expected behavior. This split matters most when correctness is in scope — a model can’t judge whether code is “wrong” without knowing what it’s supposed to do, and conflating the two in one description produces vaguer findings.
• Team conventions. Without this, a model reviews against generic best practices instead of your team’s actual standards, which can surface findings that are technically valid but irrelevant to how your team actually works.
• The output format requirement. Line number, severity, and a specific fix turns a wall of prose into something that maps directly onto a PR review — each finding is independently actionable rather than buried in a paragraph.

Three filled-in examples

Example 1 — Security-focused review

Example 2 — Reviewing AI-generated code

Example 3 — Readability and maintainability review

Common mistakes this template helps avoid

• Asking for an unscoped review. “Review this code” without a specified focus is the single most common way to get a review that looks thorough but isn’t deep enough to catch anything specific.
• Treating AI-generated code as needing less scrutiny than hand-written code. A 2024 DORA report associated rising AI coding tool adoption with small declines in delivery throughput and stability, pointing to larger change sizes as a contributing factor — AI-generated code needs the same review rigor as any other submission, plus a specific check for invented APIs and plausible-looking logic that’s subtly wrong.
• Omitting team conventions. Without them, findings default to generic best practices that may not match how your team actually works, producing technically-correct-but-irrelevant feedback.
• Pasting an entire file or repository when only a function needs review. This dilutes the model’s attention and often produces vaguer, less targeted findings than a properly scoped excerpt would.

Frequently asked questions

Should I run this on every pull request, or only larger ones?

It scales down fine for small changes — a scoped review of a five-line fix takes seconds and costs very little. The bigger question is usually which scope to run, not whether to run one at all; a small change to authentication code still warrants a security-scoped pass even if it’s short.

Can I combine multiple scopes in one review, like security and performance together?

Yes, listing several scopes works, though each additional scope dilutes depth on the others somewhat — the tradeoff is the same one that makes a fully unscoped review weaker, just less extreme. For genuinely high-stakes code, running separate passes per scope still produces deeper findings than one combined pass.

Does this replace human code review?

No — it’s a first pass that catches mechanical issues and surfaces findings a human reviewer can then evaluate, prioritize, and act on. It’s particularly useful for catching the kind of issues that are tedious to check manually every time, like scanning for a specific security pattern across a large diff, but architectural judgment and team-specific context still benefit from human review.

Why does the template ask to flag invented APIs specifically for AI-generated code?

Because it’s a failure mode specific to generated code that a human reviewer might not think to check for by default — a model generating code can reference a method or parameter that sounds plausible but doesn’t actually exist in the library being used, and that kind of error can slip past a review focused only on logic and style.

What severity levels should I use if “critical / major / minor” doesn’t match my team’s system?

Substitute your team’s actual severity scale directly in the template — the specific labels matter less than requiring the model to assign one to every finding, which is what turns a list of observations into something prioritizable.

Next steps

Pair this template with an actual workflow for running it automatically on new pull requests, or use it manually on your next review. For the broader mechanics of how agentic coding tools apply reviews like this across an entire codebase rather than one function at a time, see our guide to how AI coding assistants work. For more ready-to-use templates, browse the Prompt library.