CCAO-F 1.3 — Iterating on a prompt

The iteration loop

Write down goodwhat a finished answer must contain
Read the gapname what is missing or wrong
Change one thingthe edit that addresses that gap
Compare, don’t admirenew output against the standard
Keep the winnersave the prompt that worked

Still short? Name the next gap — one change per round

The first box is the one people skip. Without a standard written down beforehand, “better” just means “different”, and you cannot tell when to stop.

Iteration is diagnosis, not repetition

Sending the same prompt again gives you a different draft of the same misunderstanding. Adding “please be more thorough” gives you a longer draft of it. Real iteration starts with a sentence you can say out loud: “this is wrong because it covered only three of the seven regions”, or “this is wrong because the tone is for customers and I need it for the finance committee”. Until you can finish that sentence, any edit is a guess.

Most gaps fall into a handful of families, and each family has a characteristic fix. Working from the symptom to the edit is faster than rewriting from scratch, and it leaves you with a prompt you understand.

What is wrong with the output	The likely gap in the prompt	The edit
Generic — could be about any company	No source material, or no audience	Attach or paste the material; say who reads it and what they already know
Right content, wrong shape	Format was described, not specified	Give the exact sections, table columns, or a sample to match
Wrong tone or reading level	Tone left implicit	Name the reader and paste one piece of writing to imitate
Missing a section you needed	It was never asked for	List every required element; ask for “not found” where it cannot be produced
Too long, or padded with preamble	No length or structure constraint	Set a word count and say what to lead with
Drifts into general knowledge	No instruction to stay in the sources	“Use only the attached documents; say so where they are silent”
Suggests rather than does	Request phrased as a question	Phrase it as an instruction — “write”, “rank”, “rewrite”, not “could you suggest”

That last row is worth dwelling on. Anthropic’s current guidance contrasts a prompt that only invites suggestions with one that asks for the work — “can you suggest some changes to improve this function” against “change this function to improve its performance” — and notes that current models are precise instruction-followers rather than mind-readers. A surprising number of unsatisfying outputs are answers to the question that was actually asked.

Three rounds on one task

v1 — and what came backtext

Summarise this quarter's churn data.

> A readable page of prose about
> churn trends. No figures tied to
> segments. Tone aimed at nobody
> in particular.

v3 — after two editstext

For the customer success leads, who
know the product but not the finance
terms.

Using only the attached Q2 export:

- A table: segment, customers lost,
  churn %, change vs Q1.
- Under it, the three segments that
  moved most, one line each.
- Flag any segment where fewer than
  20 customers make the % unstable.

Under 300 words. No recommendations
yet — I'll ask separately.

Each version adds exactly one thing: first the audience and source, then the format, then the standard for what must be flagged. Three small edits, not three rewrites.

Change one thing at a time

When four things change at once and the output improves, you do not know which change did it — so you cannot drop the three that were useless, and you cannot reuse the one that mattered. Single changes are slower for one task and much faster across the fifty tasks like it, because they build a prompt you can explain to a colleague. They also protect you from the common trap of fixing a tone problem by adding three paragraphs of context, and then never noticing that the context was irrelevant.

There is a real exception. If the first attempt is wrong in every dimension — wrong audience, wrong source, wrong shape — you are not iterating, you are starting, and a clean rewrite using the brief structure from 1.1 beats five patches. The rule of thumb: patch when the output is recognisably the right thing done imperfectly; rewrite when it is the wrong thing done well.

Worked example · Three rounds to a usable QBR summary

Ravi runs customer success at a software firm. Every quarter he writes a business review summary for each of his eleven largest accounts. The first attempt — “summarise this account’s quarter from the attached usage data and support tickets” — produces something bland.

He writes the standard first. A usable summary names the three metrics his customers ask about, says whether each moved up or down with the number, lists open issues by age, and ends with one question to ask on the call. Four things — now he can score any draft.
Round 1 diagnosis. The draft covers usage in general terms with no numbers. The gap: he never named the metrics. One edit: name the three metrics and require the figure and the change for each.
Round 2 diagnosis. The numbers are there; the issues section lists tickets in the order they appear in the file. The gap: no ordering rule. One edit: “order open issues by age, oldest first, and give the age in days”.
Round 3 diagnosis. Good, but the closing question is generic — “how is everything going?”. The gap: he described what he wanted instead of showing it. One edit: paste three questions he has actually used, in <example> tags, and ask for one in that style.
He stops. The fourth draft meets all four standards. He saves the prompt in the Project he uses for account reviews so the other ten accounts start from version three, not version one.

Takeaway: Three rounds, three named gaps, three single edits — and a reusable prompt at the end. Had he rewritten the whole prompt each time, he would have had a good summary and no idea why.

Steer in the thread, or start again?

Once a draft exists, you have two ways to improve it, and they are not equivalent. You can steer in the same conversation — “shorten the second section, and use the client’s own words for the objection” — which keeps everything already established and is right for refinement. Or you can revise the prompt itself and run it fresh, which is right when the first attempt started from the wrong place, because a long thread carries the flawed draft along with it and later answers keep gravitating back to it.

Which move fits the problem?

What is wrong with the current draft?

Small, local fixes
Steer in the threadname the section and the change
Brief was wrong
Fix the prompt, run freshnew turn, corrected brief
Thread is long and tangled
New chat with the best versioncarry forward what worked

Refining a draft and fixing a brief are different jobs. Doing the second inside a thread full of the first is the common cause of “it keeps going back to the old version”.

Long threads have a practical cost too. As a conversation approaches the context limit, Claude summarises earlier messages so it can continue, and longer conversations consume more of your usage limit. A thread that contains six abandoned drafts is paying for all of them on every turn. Starting a clean conversation with your best prompt and the material that matters is often both cheaper and better — when to restart, summarise or persist is covered in 3.4.

Worked example · When iterating made it worse

Hannah in internal communications needs a 200-word all-staff note about an office move. After six rounds of “shorter”, “warmer”, “less corporate”, “add the date back”, the note is worse than round two and she has lost track of which version she liked.

The symptom. Every round fixed the last complaint and broke something else, because no version was measured against a fixed standard — only against the previous one.
She writes the standard down. Under 200 words; leads with the date and the address; one sentence on why; names who to contact; warm but not jokey; no mention of cost savings.
She scores the versions she still has. Round two meets four of six standards; the current version meets three. The best draft was five rounds ago.
She starts a clean conversation, pastes round two as the starting draft and the six standards as the brief, and asks for a version that meets all six.
She keeps the artifact. The note is long enough to open beside the conversation as an artifact, where she can edit it in place and switch between versions rather than re-deriving each one by chat.

Takeaway: Iteration without a fixed standard is drift. The fix was not a better prompt but a written definition of done, applied to versions she already had.

Scoring two drafts against one standard

Passes: Under 200 wordsv2: 186 · v6: 240
Fails: Leads with date and addressv6 opens with a paragraph about growth
Passes: One sentence on why
Missing: Names a contactdropped in v4 when it was shortened
Check: Warm, not jokeyv6 opens with a pun
Passes: No mention of cost savings

The same six criteria applied to both versions. This is what lets you say the earlier draft was better rather than merely preferring it.

One last point about where iteration stops. Improving a prompt makes the draft better; it does not make the draft true. A third round that finally produces the table you wanted still contains figures you have not checked. Judging the result against its sources is Domain 2 — the largest on this exam — and diagnosing persistently underperforming prompts as a troubleshooting discipline is 7.1. Iteration is the bridge between them: it is how a diagnosis becomes a better request.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Regenerating an unchanged prompt and hoping for better	Name the gap, then change the one thing that caused it.
Adding intensifiers — “be thorough”, “this is important”	Add the missing requirement, source, format or example.
Changing five things at once because the output improved	One edit per round, so you know what worked and can reuse it.
Iterating against the previous draft rather than a standard	Write down what a finished answer must contain before round one.
Patching inside a thread full of abandoned drafts	Start fresh with the corrected brief and the best version so far.

You should now be able to

Write a definition of done before the first attempt, and score every draft against it.
Diagnose an output by naming the specific gap rather than calling it disappointing.
Map common symptoms — generic, wrong shape, wrong tone, missing section — to the prompt edit that fixes each.
Make one deliberate change per round so the improvement is attributable and reusable.
Choose between steering inside a thread, revising the prompt, and starting a clean conversation.
Recognise when to stop iterating and start verifying.

Iterating on a prompt