Iterate on what came out (and test before sharing)

A sales rep asks for a renewal proposal for a client of six years. The draft has the right structure and correct prices, but it runs four pages, opens with the company history and greets “Dear Sir or Madam.” The client prefers one page and the relationship is informal.

The temptation is to open a new chat and paste the request again, or to write “this isn’t right, make it better.” Both throw away what already came out well.

Iterate in the same conversation

To iterate is to correct on top of what you already have. If the output is close, stay in the same conversation, where Claude has the request, the material and the draft, and give specific feedback:

• What to keep: “Keep the structure and prices exactly as they are.”
• What to change: “Bring it down to one page, informal tone, drop the company history, greet her by name.”
• Why, if it isn’t obvious: “She’s been a client for six years; we’re on first-name terms.”

“Make it better” doesn’t say which direction. “Shorter” without saying what to cut may cut exactly what was useful. The more precise the feedback, the fewer rounds.

Refine a little at a time

To refine usually takes two or three rounds. A few habits help:

• Fix the big things first (focus, structure, length) and the small ones later (words, the tone of one sentence).
• If a part is already right, say so: “the second paragraph stays as it is.”
• If after several rounds it still isn’t working, the problem is usually in the original request. Rewrite it with what you learned (who it’s for, what it’s for, how it should come out) instead of patching further.

Starting over makes sense in specific cases: when the whole approach was wrong, or when the conversation is so long and messy that Claude starts losing instructions from the beginning (that is covered in the product and model selection domain).

Test a prompt before sharing it

Another kind of iteration is on a prompt you will reuse. A paralegal builds a prompt that summarizes leases in a fixed table. She tries it on a recent standard lease and it comes out perfect. Now she wants to pass it to eight colleagues who handle everything from two-page licences to eighty-page agreements with side letters, some scanned and with odd numbering.

One case that went well says nothing about how it will behave with the rest. Before sharing:

1. Gather varied test cases: short, long, with amendments, scanned.
2. Include the edge cases: the odd ones, the incomplete ones, the ones that break the usual format.
3. Run the prompt on all of them and note where it fails.
4. Adjust it where it fails and test again with the same set, to make sure what worked still works.

That set of cases stays as a reference: whenever someone changes the prompt, it is tested against it again. (How to change one thing at a time when something stops working is in the troubleshooting domain.)

Common traps

Option that shows up	Why it’s wrong
Opening a new chat with the same request	Loses what was already right and probably repeats the problem
“This isn’t right, make it better”	Doesn’t say what to keep or what to change
Discarding everything and writing it by hand	Throws away a draft that was close
Sharing the prompt because it worked once	One case doesn’t represent the others
Adding “be careful with unusual cases”	Doesn’t replace testing them
Asking Claude to confirm the prompt works for everything	That’s an opinion, not a test

On the exam

If the scenario says the output “has the right structure” or “the numbers are correct” but fails on length, tone or focus, the answer is to iterate in the same conversation with what stays and what changes. If the scenario is about sharing or standardizing a prompt tested on a single case, look for the option that tests it on a varied set (including the odd cases) and adjusts it before rolling it out.