Self-Refine Prompting: 4 Recipes That Ship (2026)

Quick answer (2026): Self-refine prompting has the same model critique its own draft against a concrete rubric, then rewrite it, one pass at a time. Ship it as a bounded loop: draft, critique for concrete defects, revise, then stop after 2 to 3 passes or the moment the critique returns NO CHANGES. It lifts quality on open-ended, hard-to-check work (the original 2023 paper reports about 20% absolute average improvement), but it degrades short factual answers and never stops on its own, so bind the critique to evidence and cap the passes.

Self-refine is the loop where a model grades its own work and rewrites it. The idea comes from the Self-Refine paper (Madaan et al., 2023): one model, three prompts, generate, feedback, refine, no training. It works. The problem is that nobody ships the part that keeps it from running forever. Here are four recipes that do.

Tested on Claude and GPT, July 2026. The three-prompt structure is model-agnostic; both Anthropic's prompting docs and OpenAI's prompting guide describe the same generate, critique, revise pattern.

Recipe 1: the one-message refine pass

Claim: one message, one refine, measurable lift on open-ended writing.

Task: write a 120-word cold email asking a CTO for a 20-minute intro call.

Do this in three labeled steps, in one reply:
DRAFT: write the first version.
CRITIQUE: list up to 3 concrete defects in the DRAFT. Each defect must name the exact sentence it refers to and say why it fails (vague ask, no reason to reply, too long, generic opener). If the DRAFT has no material defect, write NO CHANGES and stop.
FINAL: rewrite the DRAFT, fixing only the defects you listed. Change nothing else.

Why it works: forcing the critique to name the exact sentence stops the model inventing cosmetic edits. "Change nothing else" stops it rewriting a good draft from scratch.

Failure mode: drop "name the exact sentence" and the critique goes abstract, then FINAL rewrites everything and you lose the parts that were already good.

Ship it: keep DRAFT and FINAL both in the output so you can diff them and confirm the change was worth it.

Recipe 2: the three-call version (paper-faithful)

Claim: split the loop into three calls when you want to log the feedback or swap models.

Call A, generate:

Write {the task}. Output the draft only.

Call B, feedback:

Here is a draft. List concrete, actionable defects as a bulleted list. Score accuracy, clarity, and brevity from 1 to 5 each. If every score is 4 or higher, reply with exactly APPROVED and nothing else.

Call C, refine:

Here is the draft and the feedback. Produce a revised draft that fixes every listed defect. Do not add new claims or facts.

Why it works: separating the feedback step lets you run the cheap draft on a small model and the critique on a stronger one, and it gives you a logged rubric you can inspect later. This is the structure the original paper uses.

Failure mode: if Call B never returns APPROVED, you loop forever. That is the whole reason for Recipe 3.

Ship it.

Recipe 3: the stopping rule (the part nobody ships)

Claim: self-refine's real bug is that it never stops. Bound it.

Refine loop:
1. Critique the current draft for concrete defects.
2. STOP and return the current draft if ANY of these is true:
   a. the critique says NO CHANGES or APPROVED,
   b. this is pass 3,
   c. the top defect is the same one as the previous pass.
3. Otherwise revise, then go back to step 1.

Why it works: an open-ended "how can this be better?" is a reward-hack surface. Ask a model to find a flaw and it always will, even in a clean draft. Quality usually peaks around pass 2 and can decay after, so the cap is not a shortcut, it is the point. Rule (c) catches the stuck case: if the model flags the same defect twice, more refining will not fix it.

Ship it: put the pass counter and the "same defect twice" check in your code, not in the prompt, so a chatty model cannot talk its way past the limit.

Recipe 4: self-refine for anything checkable

Claim: on checkable tasks, do not let the model grade itself on vibes. Make the critique cite a failing case.

Draft a function that {spec}.
CRITIQUE: trace these 4 inputs by hand and state the output for each: {input 1}, {input 2}, {input 3}, {edge case}. Report a defect only if a specific input produces a wrong output; quote the input and the wrong output. If all 4 pass, write NO CHANGES.
FINAL: fix only the inputs that failed.

Why it works: an evidence-bound critique (a concrete failing input) is far more reliable than "this could be cleaner." It turns a taste judgment into a test.

Failure mode: the model can still mis-trace code in its head. Treat this as a first pass, not a replacement for running the tests.

Ship it.

Why your refine loop never stops

If you ask "how can this be better?", the model reads it as an order to find something, and it always finds something, even on a clean draft. That is the loop people keep hitting where the model flags flaws forever. Two fixes, both above: make the critique binary and evidence-bound (name the sentence or cite the failing input, or emit NO CHANGES), and cap the passes at 2 or 3 in code.

One more boundary: self-refine helps most on open-ended, hard-to-verify work, and least on simple lookups, where it can actively degrade a short factual answer by "improving" it into something wrong. When the risk is a wrong fact, reach for chain-of-verification instead, which checks claims rather than polishing prose. When the risk is a weak-but-correct draft, self-refine is the right tool. Pair either one with chain-of-thought so the critique reasons before it judges.

Cost to test: about $0.02 a pass on a mid-tier model. The three-call version in Recipe 2 runs roughly 3x a single generation, so budget for 2 to 3 passes, not an open loop.