Review the following code change as a senior engineer responsible for production reliability. The code is: [CODE OR DIFF]. It runs in [LANGUAGE, FRAMEWORK, AND RUNTIME]. Its intended behavior is: [EXPECTED BEHAVIOR]. Relevant context, interfaces, and constraints are: [SYSTEM CONTEXT]. Test coverage or known failure reports are: [TESTS OR INCIDENT NOTES]. Do not rewrite the whole change unless a focused replacement is necessary. First summarize your understanding of the intended data flow and externally observable behavior in 3–5 bullets. Then return a review in this order: 1. Blocking findings: defects that can cause incorrect behavior, security exposure, data loss, broken compatibility, resource exhaustion, or a production incident. For each, cite the exact function, line range if available, triggering input or sequence, impact, and a minimal fix. 2. Important findings: concurrency, error handling, validation, authorization, idempotency, retries, null or empty values, time zones, pagination, numeric precision, logging of sensitive data, and API-contract risks that apply here.
3. Maintainability findings: confusing ownership, hidden side effects, duplicated logic, unclear names, weak boundaries, or tests that make future failures likely. 4. Suggested patch: only the changed snippets needed to address blocking findings, with an explanation of behavior preserved or intentionally changed. 5. Test plan: specific unit, integration, and regression cases. Include boundary values and one failure-path test for each blocking issue. Respect the existing public API and dependencies unless you explain a compatibility change. Do not claim to have run code, inspected a repository, or found a vulnerability beyond the code provided. Do not invent line numbers, package behavior, configuration, or requirements. Before answering, self-check that every finding is tied to code or stated context, and that each proposed fix actually addresses its stated trigger. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [CODE OR DIFF] | Paste the relevant file, pull request diff, or function to review. | async function refund(id) { const p = await db.payment.find(id); await stripe.refunds.create({payment_intent:p.intent}); await db.payment.update(id,{status:'refunded'}); } |
| [LANGUAGE, FRAMEWORK, AND RUNTIME] | Enter the language, framework, versions, and execution environment. | TypeScript, Node 22, Express API, PostgreSQL, Stripe SDK |
| [EXPECTED BEHAVIOR] | Describe what the changed code must do for users or callers. | An authorized support agent can refund one captured payment once, and the payment record reflects the provider result. |
| [SYSTEM CONTEXT] | Enter interfaces, data stores, authentication rules, performance limits, and compatibility constraints. | Requests may be retried by the client; payment IDs are tenant-scoped; database update and provider call are not in one transaction. |
| [TESTS OR INCIDENT NOTES] | Paste current tests, test commands, observed errors, or prior incident details. | Existing test checks a successful refund only. A prior retry created two provider refund attempts. |
How to use
- Paste a focused diff plus the behavior it is supposed to preserve; a function alone rarely reveals contract risks.
- Include retries, auth boundaries, data ownership, and known production failures because they determine the important edge cases.
- Classify the findings yourself before changing code; do not treat style comments as blockers.
- Follow up with: “Write the smallest regression tests for findings 1 and 2 using our existing test style, without changing production code.”
Variations
Security review
Use this for code that processes requests, credentials, payments, or sensitive data.
Perform a security-focused review of [CODE OR DIFF] in [STACK]. The trust boundaries are [TRUST BOUNDARIES], and the code handles [SENSITIVE DATA]. Look specifically for authorization gaps, tenant isolation failures, injection, unsafe deserialization, SSRF, path traversal, secret exposure, insecure redirects, replay, rate-limit bypass, and logging leaks where applicable. For each confirmed concern, show the attack precondition, exploit path, impact, and a minimal remediation. Distinguish definite issues from hardening suggestions. Do not invent infrastructure details or claim a penetration test. Ask up to 3 questions only if required input is missing.
Performance review
Use this for slow endpoints, batch jobs, or code on a hot path.
Review [CODE] for performance and reliability under [WORKLOAD]. The current symptoms and limits are [MEASUREMENTS OR SLOS], and its dependencies are [DEPENDENCIES]. Trace likely time, memory, database, network, and queue costs. Identify N+1 queries, unbounded reads, repeated serialization, excessive allocations, contention, retry storms, missing timeouts, and backpressure problems where supported by the code. Rank fixes by expected impact, implementation risk, and measurement needed to validate them. Supply a benchmark or observability plan. Do not invent throughput or query plans. Ask up to 3 questions only if a required input is missing.
Pull request review
Use this when you want concise review comments for a team workflow.
Review this pull request diff: [DIFF]. The ticket intent is [TICKET OR EXPECTED BEHAVIOR], and the repository conventions are [CONVENTIONS]. Return only actionable review comments, grouped as Blocker, Important, and Nit. Each comment must name the code location, explain the failure mode in plain language, and suggest a concrete change or test. Check backward compatibility, error paths, observability, and tests as relevant. Avoid praise, restating code, and speculative comments. Do not assume files outside the diff exist. Before answering, remove any comment not supported by the supplied material. Ask up to 3 questions only if required input is missing.
Tips
- Review the diff against an explicit behavioral contract; correctness is often broken at the boundary between the new code and an unstated caller expectation.
- For writes to external systems, ask about retries and idempotency because a successful retry can be as dangerous as a failed first attempt.
- Ask for an exact trigger for every finding; this filters out vague warnings and turns the review into a reproducible test case.
- Treat generated patches as proposals and run the project’s formatter, tests, type checks, and security tooling before merging.
FAQ
Can I paste a whole repository into a code review prompt?
A focused diff plus relevant interfaces and tests usually produces a better review. Large repositories hide the behavior change and consume context.
Should AI rewrite the code after reviewing it?
Ask for a minimal patch only after agreeing on the findings. A full rewrite can introduce unrelated compatibility and operational risks.
What information helps most with edge cases?
Request lifecycle, retry behavior, authorization model, database constraints, external APIs, and a real failed case are more useful than general architecture prose.