Code Review Prompts with Evidence and Priorities

This reviewed prompt collection is for developers, reviewers, and technical leads. Do not paste secrets, proprietary code, credentials, or regulated data into an AI product without authorization.

When to use these prompts#

Use this page when you need language-aware prompts that require context, expected behavior, risk categories, evidence from the supplied code, prioritized findings, and test suggestions. Replace every bracketed variable with verified, non-sensitive information before using a template in your own AI product.

Inputs to prepare#

• language, version, framework, and runtime
• change goal and expected behavior
• diff plus relevant surrounding code
• architecture and data-flow context
• security and reliability requirements
• known constraints and accepted trade-offs
• existing tests and failing cases
• review categories and severity definitions

Draft prompt templates#

1. Pull request review#

Purpose: Produce prioritized findings tied to supplied code.

Review this [LANGUAGE/FRAMEWORK] change for correctness, security, reliability, performance, maintainability, and tests. Goal: [EXPECTED BEHAVIOR]. Context: [ARCHITECTURE]. Constraints: [CONSTRAINTS]. Code or diff: [CODE]. For each finding provide severity, exact evidence, failure scenario, confidence, suggested fix, and test. Do not report a problem without pointing to supplied code or a missing context question.

Before use, remove irrelevant fields, replace every placeholder, and verify that the requested judgment can be supported by the material you supplied.

2. Security-focused review#

Purpose: Check a defined threat model without claiming a full audit.

Review [CODE] against this threat model: [ASSETS, TRUST BOUNDARIES, ATTACKERS, INPUTS]. Focus on [RISK AREAS]. Distinguish confirmed vulnerabilities, plausible risks needing reproduction, and hardening suggestions. Include evidence and a safe test approach. Do not claim the review proves the code secure or expose real secrets in examples.

Before use, remove irrelevant fields, replace every placeholder, and verify that the requested judgment can be supported by the material you supplied.

3. Review false-positive challenge#

Purpose: Reassess findings before posting them to a pull request.

Challenge the following review findings against [CODE AND CONTEXT]: [FINDINGS]. For each, identify assumptions, whether the behavior is reachable, counter-evidence, and the minimum reproduction needed. Mark keep, downgrade, remove, or ask for context. Then rewrite only the supported comments in concise pull-request language.

Before use, remove irrelevant fields, replace every placeholder, and verify that the requested judgment can be supported by the material you supplied.

Why the structure matters#

Code review is most useful when every comment is connected to expected behavior and evidence. These prompts ask for severity, confidence, failure scenarios, and tests, which helps reduce generic advice and unsupported warnings.

Weak prompt and what it misses#

Find all bugs and security issues in this code and fix everything.

No runtime, expected behavior, architecture, threat model, or test context is supplied. “All” is impossible to establish, and the model may produce false positives or rewrite code beyond the requested scope.

Human review checklist#

• Remove credentials, tokens, customer data, and proprietary material before external processing.
• Reproduce high-severity findings locally before acting on them.
• Review suggested dependencies and APIs against official documentation.
• Run the project’s tests, linters, type checks, and security tooling.
• Treat the AI review as one input, not an approval gate.

Testing and maintenance#

1. Use original, non-sensitive sample values when testing a prompt.
2. Retest examples after material changes to the prompt, page, or AI product.
3. Check factual preservation, requested format, missing-data behavior, and task-specific risks.
4. Update the visible test date when a material retest is completed.
5. Keep the site operator responsible for the final human review.

A dated operator attestation is sufficient for the site's internal publication check; full chat transcripts are not retained or published.