Prompt Review Checklist

Maya needs cursor pagination on the orders export. She types "add pagination to the orders export, make it fast" and sends it. The assistant guesses a framework, invents a response shape, and rewrites a file she only wanted patched. She retypes the request with slightly different words. Same class of miss. Four round trips later she has spent more time steering than the change would have taken to write by hand. The prompt was missing the facts the model could not invent, and rephrasing the same gap a fourth time supplies none of them.

This is the gap the review closes. A language model fills every blank you leave with the most probable guess, and a probable guess is not your codebase. Anthropic's own prompting guidance frames the model as a brilliant but new employee who lacks context on your norms and workflows, and offers a test worth memorizing: show your prompt to a colleague with minimal context on the task and ask them to follow it. If they would be confused, the model will be too. That single rule catches most of what this checklist itemizes.

Skipping the review starts a loop, and the loop is the real cost. Each retry feels cheap, so you never stop to diagnose, and the loop quietly eats more time than reading your draft once would have. The review is a deliberate pause that turns "send and see" into "check and send". Thirty seconds against a ten-line list is almost always cheaper than a second wrong response, because a wrong response still has to be read, judged, and replaced. The checklist is the structured version of the colleague test: instead of hoping you remembered the file path and the constraint, you confirm each one before the model ever sees the request.

Every line is a yes/no you answer by reading your own draft. The skill is telling a real yes from a yes you wish were true. Here is what strong looks like next to weak on the lines people fumble most.

• Role and goal. Weak: "help me with the export." Strong: "You are working in our Node admin service; add cursor pagination to the orders export so a client can fetch 10k rows in pages without timing out." The strong version names the role and a checkable outcome in one breath.
• Context, present and trimmed. Two failure modes pull in opposite directions. Weak by omission: no file path, no framework, no mention that the export already streams. Weak by flooding: the entire 800-line file pasted in when only the handler matters. Strong: the file path, the one helper to reuse, and the one rule that constrains the change. Anthropic suggests expressing context as a short set of decision-shaping facts and keeping raw material clearly separated, so the facts that steer the answer are not buried under the ones that do not.
• Constraints as rules. Weak: "make it fast" or "keep it clean," which the model cannot act on. Strong: "do not change the response schema beyond adding nextCursor; reuse paginate() from lib/pagination.ts; keep the handler under 80 lines." A constraint the model can verify against is a constraint that survives contact with the output.
• Output format named. Weak: leaving it open, then being annoyed it rewrote the file. Strong: "return a unified diff only, no prose," or "return JSON with keys orders and nextCursor." When the shape is easy to get wrong, add one short example. Anthropic's guidance is blunt here: one good example beats five adjectives, and few-shot examples (use three to five, each wrapped so it reads as a sample) are among the most reliable ways to pin format and tone.
• Positive phrasing. Weak: "do not use markdown." Strong: "respond in plain prose paragraphs." Telling the model what to do steers it more reliably than telling it what to avoid, because the instruction points at a target instead of a wall.
• Instruction placed last. When you paste a long file or log, put the actual request after it. Anthropic reports that moving the query to the end of a long-context prompt can lift response quality by up to 30% on complex, multi-document inputs. A request stranded in the middle competes with everything around it.
• Testable success and handled uncertainty. Weak: "make it good." Strong: "stays under 200 ms for 10k rows," plus a line telling the model to stop and ask if the helper does not fit rather than inventing a new one. A definition of done you could write a test for is one you can actually check.

You do not need a perfect score. You need to find the one line that is a real no and fix that one. Most failed prompts miss a single thing, and the fix is usually a sentence, not a rewrite.

A few traps make the checklist feel done while the prompt is still weak.

• Ticking boxes you wish were true. The point of failure is reading "constraints explicit" and thinking "fast counts." It does not. If you cannot imagine the test, the line is still a no. Be your own skeptical colleague.
• Confusing review with evaluation. This checklist judges one prompt before it runs. It says nothing about whether the prompt holds up across many inputs over time. A prompt that passes review can still drift or fail on the inputs you did not picture. That ongoing question belongs to the Prompt Evaluation Checklist, which scores outputs against a rubric over a fixed input set of roughly 50-200 cases, the small curated golden set teams run on every change to catch regressions. Use review to ship a good first prompt; use evaluation to trust a prompt you depend on.
• Over-armoring the prompt. Older habits push people to shout: "CRITICAL: you MUST return JSON, NEVER add prose." Current models follow normal instructions well and can overtrigger on forceful, all-caps wording, doing more than asked or treating every clause as urgent. Dial it back to plain phrasing. The clarity does the work, not the volume.
• Treating the review as the whole job. A clean prompt produces a response; it does not vouch for it. The review ends the moment the model replies. From there the output is just code, and code earns trust by being read.

On a team, the review pays off twice. A prompt one person reviews well becomes a prompt anyone can reuse, because the role, context, and format are on the page instead of in one person's head. Saved prompts, a project's CLAUDE.md, and shared snippets are where good reviewed prompts go to live, so the next person starts from a passing draft.

For your next real task, do not adopt all ten lines at once. Pick the line you skip most, probably "output format named" or "success is testable," and force a yes on it before your next send. When you are scoping coding work, start at the AI Coding Session Brief and Giving AI the Right Context so the prompt has facts to reference. When the assistant returns a diff, move to the AI Code Review Checklist and the Reviewing AI Code Safely guide. The review gets you a strong question; those handle whether you can trust the answer.