Add a self-critique pass before the final answer

Answering and checking an answer are two different jobs. Ask for both in one pass and the first one wins. A separate, explicit check step catches what the drafting pass misses.

The two-step shape

Step one: produce the answer as usual. Step two, as its own instruction, either a second message or a marked second section of the same prompt: check the answer above against this list: [specific things that go wrong for this task]. Fix anything that fails, or say it already passes.

Why a specific checklist beats check your work

Double check your answer yields very little. The model rereads what it already believes is right and, unsurprisingly, agrees with itself. A specific list of known failure modes gives it something concrete to hunt for: invented numbers, an unstated assumption presented as fact, a claim with no support in the source. Was I right is a question it cannot judge from the inside.

What goes on the checklist

Take it from what really goes wrong for the task in front of you and skip generic lists. For extraction: did anything get invented instead of left null? For a rewrite: did anything change that was meant to stay fixed? For a summary: does every claim trace back to the source? For code: does it compile, and did an import get renamed inconsistently?

Where it earns its cost

It doubles the tokens and the wait, so it is no fit for every message. Use it where a human checks the result least: an automated pipeline, a first draft heading straight to a customer, code applied without review. There, catching a mistake before it ships is worth twice the price.

A shorter version for everyday use

For a lower-stakes task, one added sentence does most of the work: before answering, check whether you are inventing any detail not present in the input, and if you are, remove it or flag it.