Lesson 3.4: Self-checks, revision and improving your own prompt
Learn to run a draft, critique and revise loop with a rubric, know what a model's self-review can and cannot catch, and use it to improve your prompts.
By the end of this lesson you will be able to run a draft, critique and revise loop with criteria you set, choose a reviewer role that finds real weaknesses, understand what a model's review of its own work can catch and what it misses, stop revising when more rounds stop paying, and use the model to improve the prompt itself by exposing gaps, asking you questions and proposing test cases. You will see why each revision round gains less than the last, and how to keep a model-written prompt from growing longer and vaguer. You should have read Lessons 1.4, 2.4 and 3.2, since this lesson uses sharp instructions, the limits of checking, and the draft-critique-revise pattern from the chaining lesson. No technical background is needed.
Good writers do not ship a first draft. They write, step back, find what is weak and fix it. A model can do each of those moves on request, and the loop is one of the simplest ways to lift the quality of a reply without any new information from you. It is also easy to misuse. This lesson shows how to run it well, where it stops helping, and how to turn the same idea on your own prompts.
The draft, critique, revise loop
The loop has three prompts, and each does one job.
1. Draft. Ask for a first version, as you normally would.
2. Critique. Ask the model to review that draft against specific criteria and list what falls short. Do not ask it to fix anything yet.
3. Revise. Ask for a new version that addresses the listed problems and changes nothing else.
Separating the second and third steps matters. If you ask for "a better version" in one go, the model rewrites everything and you cannot see what changed or why. If it first produces a list, you can read the list, strike the points you disagree with and add some of your own before any rewriting happens. The critique becomes a checkpoint of the kind Lesson 3.2 described.
Predict first: you ask an assistant to "improve" a draft email without saying how. What do you expect it to change, and what might it leave alone? Decide before reading on.
An unspecified request to improve usually produces a tidied, slightly longer, more formal version: smoother phrases, extra pleasantries, a more confident tone. It rarely fixes the issues that matter to you, such as a missing deadline, a buried request or the wrong level of formality, because you did not say what good looks like. A critique is only as good as its criteria.
Critique with criteria, not a feeling
The strength of a critique depends on the rubric you supply. Compare two prompts.
> Review this email and tell me how to make it better.
> Review the email below against these five criteria and score each from 1 to 5, with one sentence of evidence: (1) the request is stated in the first two sentences, (2) the deadline is explicit, (3) the tone suits a senior client, (4) it is under 120 words, (5) it contains no claim that is not in the facts I gave. List every criterion that scores below 4 and say exactly what to change. Do not rewrite the email yet.
The second gives the model something to measure against and gives you something to check. Build your criteria from the prompt itself: each constraint you wrote becomes a criterion. If you said "under 120 words", the critic should check it. Criteria also stop the critic from inventing its own taste, which would pull your piece away from your voice.
A few kinds of criterion are worth reusing.
Kind · Example criterionCompleteness · "Does it state the decision, the owner and the deadline?"
Accuracy against the source · "Is every figure found in the facts provided?"
Clarity · "Could a new colleague act on this without asking a question?"
Tone · "Is it polite and direct, with no blame?"
Format and length · "Is it under 150 words and in three bullets?"
Risk · "Does anything promise an outcome we cannot guarantee?"
## Choosing a reviewer
A critique tends to be sharper when the reviewer has a point of view. Rather than "review this", try a role with a stake.
The sceptical reader: "You are a busy director who will only read the first three lines. What would you miss, or misread?"
The expert editor: "You are a strict editor. Cut anything that does not carry information."
The affected person: "You are the customer who receives this. What would annoy or confuse you?"
The red team: "List three ways this plan could fail, and the earliest warning sign of each."
The risk reviewer: "Find any sentence that makes a promise, a legal claim or an unsupported statistic."
Different reviewers find different problems, so it can pay to run two. As Lesson 1.3 noted, a role sets perspective and does not supply expertise, so use it to find weaknesses and not to certify correctness. A reviewer who says "this is well written" has told you very little.
The chart illustrates the central limit of self-review, which the next section explains.
What self-review can and cannot catch
It is tempting to treat the loop as a way to make the model check itself and so become reliable. That overstates it. A model reviewing its own text shares its own blind spots and knows only what is in the prompt. The honest division is this.
Reviewer · Good at catching · Weak at catchingThe same model, on its own draft · Wordiness, tone, structure, missing parts, inconsistency within the text · Facts it cannot see, errors it would make again, flattering itself
A different model or a fresh chat · A second view, some different mistakes · Facts outside the prompt, errors both share
A check against the source · Invented or altered facts, if the source is supplied · Judgement and style
A person who knows the subject · Wrong facts, context, what matters · Spotting every slip at speed
Three failure modes deserve a warning.
Flattery. Ask "is this good?" of a draft the model wrote itself, and it tends to say yes. A critique prompt that demands a list of problems, with a minimum of three, avoids this: "List at least three weaknesses, even if the draft is strong."
Over-polishing. Repeated revision can strip a piece of personality, replacing a distinctive voice with smooth, generic prose. Each round trades some sharpness for safety. Keep your original, compare versions and be willing to go back.
False comfort on facts. A reviewer who is given no source cannot confirm a figure. If the draft says "revenue grew 14 per cent" and the critic replies "the figures look accurate", it has simply read the claim and found it plausible. Fact-checking needs the source, as Lesson 2.4 explained, or you.
So use the loop for what it does well, which is form, completeness and consistency, and keep your own checking for truth.
How many rounds?
Each round of revision usually gains less than the one before. The first critique finds the biggest problems, and later rounds polish smaller ones. Suppose a draft scores 6 out of 10 on your rubric, the first revision lifts it by 1.5 points, and each later round gains half of the previous one: 0.75, then 0.375 and so on. The scores are 6, 7.5, 8.25, 8.63 and 8.81. The fourth round adds about 0.19 points, and if each round takes four minutes of your time, that gain costs more than 20 minutes per point.
A practical stopping rule: stop when a critique finds nothing you would act on, or when the changes begin to cancel each other out, one round shortening a sentence and the next lengthening it. For important pieces two rounds are usually plenty. For routine ones, a single critique is often enough.
Turning the loop on your prompt
Everything above also works on the prompt itself. A prompt is a piece of writing with a reader, and the reader happens to be the model, so you can ask the model to help improve it. This is sometimes called meta-prompting: prompting about prompting. Four moves are useful.
1. Ask what is unclear
text
Here is a prompt I plan to use. Do not answer it. Instead, list (a) anything
ambiguous, (b) any information you would need that is missing, (c) places where
you would have to guess, and (d) any instructions that conflict.
Prompt:
"""
[PASTE YOUR PROMPT]
"""
The reply is a free audit against the new-colleague test of Lesson 1.1. The "places where you would have to guess" line is the most valuable, because each guess is a gap you can close.
2. Let it interview you
Instead of writing a long prompt from scratch, ask the model to gather what it needs.
text
I want help drafting a weekly status update for my director. Before you write
anything, ask me up to five questions, one at a time, to learn what you need.
When you have enough, write a prompt I can reuse for this task.
The interview approach suits people who find it hard to know what to include, and it often surfaces details you would have forgotten.
3. Ask for a rewrite, and read it critically
You can ask: "Rewrite this prompt to be clearer and more specific, keeping my intent. Explain each change." The risk is that model-written prompts grow longer, more generic and full of boilerplate such as "you are a world-class expert". Apply the test from Lesson 1.4 to every line the model added: does it close a real gap, or is it padding? Keep the lines that do and cut the rest. The explanations help you learn what the model considered missing.
4. Ask for test cases
A prompt is only as good as the cases it handles, so ask the model to find the hard ones.
text
Here is my prompt for classifying customer messages. Write ten realistic test
messages that would be hard for it, including borderline cases, messages with
two issues, and messages in mixed Hindi and English. For each, say which
category you think is correct and why.
You now have a set of tricky inputs to run through your prompt, which is the start of a real test set. Check the model's expected answers yourself, since the "correct" category it proposes may be wrong. Module 5 shows how to turn this into a proper evaluation.
Comparing versions honestly
When you change a prompt, you want to know whether the new version is better, and a single good-looking output proves little. A small discipline helps.
Change one thing at a time, so you know which edit mattered.
Run each version on the same set of cases, at least eight to ten, including awkward ones.
Score with the same rubric, and, where possible, score without knowing which version produced which output.
Keep a change log: the date, what you changed, why and what you saw.
Remember the noise. Outputs vary run to run, and a handful of cases cannot separate small differences. Prefer large, clear gains, and repeat important comparisons.
If version B wins on seven of ten cases and version A on three, that is a lean in B's favour, not a proof. If B wins on ten of ten, you can be fairly confident. Lesson 2.1 gave the arithmetic: small test sets have wide margins of error.
Worked examples
Example 1: revising an email with a rubric. A project manager drafts an email asking a client to approve a revised plan. She runs a critique against five criteria: the request in the first two sentences, an explicit deadline, tone for a senior client, under 120 words and no unsupported claims. The critique scores the request at 2 (it appears in the fourth sentence), the deadline at 1 (it says "soon") and the length at 3 (150 words). She approves those three fixes and asks for a revision that changes nothing else. The second version states the request first, gives "by Friday 6 November" and is 110 words. One round was enough.
Example 2: improving a classification prompt with hard cases. A team's prompt labels support messages. They ask the model for ten hard test messages, and run them. The prompt mislabels three: two with two issues in one message and one that is a complaint phrased as a question. They add a rule, "If a message contains two issues, label the one that needs action first, and say so", plus one example of a complaint phrased as a question. Re-running the ten, nine are now right. They also notice that the model's own "expected" label for one message was wrong, a reminder that the checker needs checking.
Example 3: a critique that backfired. A writer asks for "improvements" to a lively product description through four rounds. Each round makes it more polished and more generic, until it reads like every other description. Comparing the first and the fourth, she sees that the distinctive opening line has been replaced with a stock phrase. She goes back to version two, takes only the fix for a wrong date from later rounds and stops. The lesson is to keep every version, to name what each round should change and to be ready to stop.
Common mistakes
Asking for "a better version" with no criteria. You get smoother, longer text, not the fixes you need.
Revising and critiquing in one step. You cannot see or veto the changes. List first, then rewrite.
Asking "is this good?" The model tends to agree. Demand a list of weaknesses.
Trusting self-review on facts. The reviewer cannot confirm what it has not seen. Check against the source.
Over-polishing. Rounds beyond the second or third often flatten the voice. Keep your versions and stop when gains fade.
Accepting a model-rewritten prompt unread. Check that each added line closes a gap, and delete boilerplate.
Judging a prompt on one output. Compare on a set of cases with a fixed rubric.
Changing several things at once. You will not know which edit helped.
Key takeaways
The draft, critique, revise loop separates writing from judging: ask for the problems first, approve or edit the list, then ask for a revision that changes only those points.
A critique needs criteria. Turn each constraint in your prompt into a rubric item, and give the reviewer a role with a stake, such as a sceptical director or a customer.
Self-review is good at form, completeness and consistency, and poor at facts. It flatters, so demand at least three weaknesses, and it can over-polish, so keep your versions.
Gains shrink with each round. In the example, round four added under 0.2 points at over 20 minutes a point. Two rounds are usually enough.
Use the model to improve your prompt: list what is unclear, let it interview you, ask for a rewrite you read critically, and have it generate hard test cases.
Compare versions on the same set of cases with the same rubric, change one thing at a time and keep a change log.
Check yourself
1. Why ask for a critique before asking for a revision?
You can read, edit and veto the list of problems, and you can see what changes, instead of getting a full rewrite you cannot trace.
2. What are two things self-review is poor at?
Checking facts it was not given, and noticing errors it would make again. It can also flatter its own draft.
3. A draft scores 5, the first revision adds 2 points, and each later round adds half the previous gain. What is the score after three rounds?
5 + 2 + 1 + 0.5 = 8.5.
4. What does the line "list the places where you would have to guess" reveal?
The gaps in your prompt, because each place where the model would guess is an unspecified detail you can close.
5. A new prompt version beats the old on 6 of 10 cases. How confident should you be?
Only slightly. A small test set has a wide margin of error, so repeat on more cases before deciding.
Try this
You need an assistant and about fifty minutes.
1. Take a draft you wrote this week, such as an email, a short report or a summary. Write a five-point rubric from the constraints you care about.
2. Run the critique prompt with your rubric, asking for at least three weaknesses and no rewriting. Strike any point you disagree with.
3. Ask for a revision addressing only the remaining points. Compare it with your draft, line by line, and note anything lost.
4. Run a second round, and compare. Record the rubric score after each version with the simulator, and note the minute cost, to decide where you would stop.
5. Take a prompt you use regularly. Run the three audit moves: ask what is unclear, ask for the places the model would guess, and ask for ten hard test cases. Check the model's expected answers yourself.
6. Revise the prompt to close the gaps, keeping each added line only if it closes one. Run old and new on the ten cases and score both.
7. Fill in this table.
Item · Version 1 · Version 2 · Version 3Rubric score (out of 5) · · ·
Minutes spent · · ·
What changed · · ·
What was lost · · ·
A good result is a saved rubric, a draft that improved on at least three criteria in two rounds or fewer, an improved prompt with a change log and a clear note on when you would have stopped. With this lesson Module 3 is complete. You can ask a model to reason, split big jobs into steps, keep your standing instructions and templates in order, and use its review to improve both your work and your prompts. Module 4 applies all of this to the jobs most professionals do every week: writing, research, analysis and planning.
Tags: Prompt Engineering Revision Self-critique Meta-prompting Prompt improvement