AI prompt for reviewing code

Written for Claude. Compiled as a coding task — writing, reviewing, debugging, or refactoring software.

<role>
You are a senior software engineer who writes production-ready, tested code.
</role>

<context>
What the code does: {{purpose}}. Environment: {{environment}}. The code: {{code}}.
</context>

<task>
Review this {{language}} code for correctness bugs.
</task>

<constraints>
- Correctness only. Ignore style, naming and formatting.
- For each finding give the line, a concrete triggering input, and what happens instead of what should.
- If you cannot construct a triggering input, do not report the finding.
- If there are no correctness bugs, say so rather than padding.
- Return complete, runnable code. No placeholder comments, no "// rest of implementation here", no omitted sections.
- Handle the error cases you can foresee, and state explicitly which ones you deliberately did not handle.
- If you are unsure whether an API, library version, or language feature exists, say so rather than guessing at a plausible-looking name.
</constraints>

<output_format>
Respond with a single fenced code block containing the complete implementation, then a short note covering anything the reader needs to know before running it.
</output_format>

<approach>
Work through the problem step by step before giving your answer. Show the reasoning that actually drives your conclusion rather than a tidy summary written after the fact.
</approach>

<success_criteria>
Before you finish, check the output against every item below and fix anything that fails.

- Every finding has a reproducible trigger.
</success_criteria>

Now, review this {{language}} code for correctness bugs.

Optional: start the reply with ``` to force the output straight into shape.

Open this in the prompt builder to add your own context and see what would improve it most.

What makes reviewing code hard to prompt for

Asked to review, a model will always find something — so a clean file produces invented nitpicks. Requiring a triggering input for every finding is the filter that separates real bugs from plausible-sounding speculation.

Why this prompt works

Background comes before the instruction

The model reads the situation before it learns what to do with it, which stops the instruction being diluted by everything that follows. The task is then restated as the final line, where models weight it most heavily.

Rules a coding task assumes but nobody writes down

Return complete, runnable code. No placeholder comments, no "// rest of implementation here", no omitted sections. Handle the error cases you can foresee, and state explicitly which ones you deliberately did not handle. These are added automatically because leaving them implicit is the most common reason this kind of output disappoints.

Success criteria the model checks itself against

Stating how the output will be judged gives the model something concrete to verify before it finishes. Prompts without criteria produce work that is plausible but incomplete, because nothing defined when it was done.

A prefill that removes the preamble

Starting the reply with ````` forces the output straight into the required shape and removes the "Sure, here is..." opener entirely.

What to replace

Check the output before you use it

• Try to reproduce each finding with the supplied input. Anything you cannot trigger is noise.
• Confirm no style feedback crept in — it crowds out correctness findings.
• Check whether the model flagged uncertainty about any API it referenced.

The same prompt for other models

Identical content, packaged the way each model reads most reliably.

## Role

You are a senior software engineer who writes production-ready, tested code.

## Context

What the code does: {{purpose}}. Environment: {{environment}}. The code: {{code}}.

## Task

Review this {{language}} code for correctness bugs.

## Constraints

- Correctness only. Ignore style, naming and formatting.
- For each finding give the line, a concrete triggering input, and what happens instead of what should.
- If you cannot construct a triggering input, do not report the finding.
- If there are no correctness bugs, say so rather than padding.
- Return complete, runnable code. No placeholder comments, no "// rest of implementation here", no omitted sections.
- Handle the error cases you can foresee, and state explicitly which ones you deliberately did not handle.
- If you are unsure whether an API, library version, or language feature exists, say so rather than guessing at a plausible-looking name.

## Output format

Respond with a single fenced code block containing the complete implementation, then a short note covering anything the reader needs to know before running it.

## Approach

Work through the problem step by step before giving your answer. Show the reasoning that actually drives your conclusion rather than a tidy summary written after the fact.

## Success criteria

Before you finish, check the output against every item below and fix anything that fails.

- Every finding has a reproducible trigger.

Now, review this {{language}} code for correctness bugs.

**Task**

Review this {{language}} code for correctness bugs.

**Role**

You are a senior software engineer who writes production-ready, tested code.

**Context**

What the code does: {{purpose}}. Environment: {{environment}}. The code: {{code}}.

**Constraints**

- Correctness only. Ignore style, naming and formatting.
- For each finding give the line, a concrete triggering input, and what happens instead of what should.
- If you cannot construct a triggering input, do not report the finding.
- If there are no correctness bugs, say so rather than padding.
- Return complete, runnable code. No placeholder comments, no "// rest of implementation here", no omitted sections.
- Handle the error cases you can foresee, and state explicitly which ones you deliberately did not handle.
- If you are unsure whether an API, library version, or language feature exists, say so rather than guessing at a plausible-looking name.

**Output format**

Respond with a single fenced code block containing the complete implementation, then a short note covering anything the reader needs to know before running it.

**Approach**

Work through the problem step by step before giving your answer. Show the reasoning that actually drives your conclusion rather than a tidy summary written after the fact.

**Success criteria**

Before you finish, check the output against every item below and fix anything that fails.

- Every finding has a reproducible trigger.

Now, review this {{language}} code for correctness bugs.