Prompt template
A code review prompt built for findings you can act on.
This reusable template gives a coding agent the change, intended behavior, constraints, and known validation before asking for findings. It is designed to reduce generic summaries and make uncertainty visible.
Reviewed September 22, 2026 · Templates and examples use fictitious data.
When to use this code review prompt
Use it after a change is ready to inspect but before treating the work as complete. It works for pull requests, local diffs, a set of changed files, or a narrowly described implementation. The reviewer still needs access to the relevant code and tests; the prompt does not replace that evidence.
The template is especially useful when you want the review to prioritize behavior and risk instead of restating the diff. It asks the reviewer to inspect affected call paths, distinguish confirmed problems from missing context, and avoid claiming that unexecuted tests passed.
Reusable template
Code review prompt
# Review {{change}}
## Goal
Review {{change}} in project {{project}} and identify issues that could affect users or maintainers.
## Context
- Intended behavior: {{expected_behavior}}
- Relevant constraints: {{constraints}}
- Validation already performed: {{validation}}
<instructions>
Inspect the changed code and the affected call paths. Prioritize defects, regressions, security, data integrity, accessibility, performance, and missing tests.
Base every finding on concrete evidence. Do not invent failures or claim that a test passed unless it was run. If context is missing, state the uncertainty and the exact check needed.
</instructions>
<output_format>
1. Findings ordered by severity, each with evidence, impact, and a practical correction
2. Open questions or assumptions
3. Validation and test gaps
4. Short summary if no blocking issue is found
</output_format>What to fill in
{{change}}
The branch, pull request, diff, feature, or changed files that define the review boundary.
{{project}}
The repository or product context. Include related services only when they affect the change.
{{expected_behavior}}
What users or dependent systems should observe after the change.
{{constraints}}
Compatibility, security, performance, accessibility, or migration requirements that cannot be inferred from code alone.
{{validation}}
Tests and checks already run, including failures or checks that were not possible.
Filled example
Change: Replace session lookup middleware with a cached lookup.
Project: TypeScript API used by the web and mobile clients.
Expected behavior: Authenticated requests keep the same authorization decisions while repeated lookups within one request are avoided.
Constraints: Revoked sessions must stop working immediately; logs cannot contain tokens; existing public error codes must remain stable.
Validation: Unit tests passed. Revocation and concurrent-request scenarios have not been tested.
A useful answer should now focus on invalidation, request boundaries, authorization decisions, sensitive logging, concurrency, and the missing revocation test. Without this context, a reviewer may spend most of the answer describing the cache implementation.
How to evaluate the result
- Every finding points to specific behavior or evidence.
- Severity reflects user impact, not stylistic preference.
- Unknowns are labeled instead of presented as defects.
- Suggested tests describe the scenario and expected result.
- A proposed correction preserves the constraints supplied in the prompt.
If the answer is still generic, narrow {{change}}, add the relevant files or diff, and make the intended behavior more concrete. A larger prompt is not automatically better; relevant evidence is.
Limits
A prompt cannot give an agent access to code, logs, or test output that the tool does not already have. It also cannot prove correctness. Treat the response as a set of review findings to verify, not as an approval signal.