A better prompt starts with the yardstick, not the wording. Write down when an answer counts as good, build a set of test cases, then change the prompt. Anthropic calls that cycle central to prompt engineering [S-084]. Skip it and you can only see that the output changed, not that it improved.
This is for a marketing lead who uses AI every day and cannot separate a good answer from a plausible one. There is no acronym here, no promise of a flawless wording, and no percentage about what a technique gains you. Getting people to use AI at all is a different question, covered in get your team to use AI.
How do you know a prompt actually got better?
You do not, unless the measure existed first. The order in the documentation is success criteria, then evaluations that measure against them, then the prompt. Building an application on a model starts with clearly defining your success criteria and then designing evaluations to measure performance against them, and that cycle is central to prompt engineering [S-084].
The guide itself is sharper still. It assumes you already have three things before you start: a clear definition of the success criteria for your use case, some ways to empirically test against those criteria, and a first draft prompt you want to improve. If not, it says, spend time establishing that first [S-085].
That reverses the usual order. Success criteria and evals first, the prompt second. Every guide written for this question starts at the third item and ends at “and now your prompt is better”; the vendor of the model treats the first two as the entry requirement.
The reason is regression. A rewritten prompt fixes the case in front of you and breaks three you are not looking at: tone drifts, a field disappears, an edge case starts failing. Without a fixed set of cases you are not improving a prompt, you are trading one set of errors for another.
What makes a success criterion you can check?
One that is specific, measurable, achievable and relevant, so “accurate sentiment classification” rather than “good performance” [S-087]. Even vague subjects are quantifiable: the documentation replaces “safe outputs” with “less than 0.1% of outputs out of 10,000 trials flagged for toxicity by the content filter” [S-087]. The second version can be checked by someone who did not write the prompt.
Translated to the work a marketing team hands over:
| Criterion as people state it | Version you can check | What grades it |
|---|---|---|
| A good summary | Names the decision, the owner and the deadline, and nothing else | Code, on the three fields |
| A usable product description | Only attributes from the data sheet, inside the length your template allows | Code for length, a person for tone |
| A professional reply to a customer | Answers the question asked, names the next step, states no date that is not in the system | A model with a rubric, audited by a person |
| Safe output | The documented example: fewer than 0.1% of outputs flagged for toxicity over 10,000 trials [S-087] | Code |
The threshold is yours. It comes out of your own data and your own tolerance for a mistake, not out of an article. What matters is that it is written down before anyone edits a prompt.
How do you build a test set that tells you something?
With more cases than feels comfortable, graded automatically. The documentation gives three design rules for evaluations [S-088]:
- Be task specific. Mirror your real-world task distribution, and factor in edge cases [S-088]. If one in ten briefs arrives without a product name, one in ten test cases arrives without one.
- Automate when possible [S-088]. A grader you run in a minute gets run after every change; one that needs an afternoon gets run once.
- Prioritise volume over quality. More questions with slightly lower signal automated grading is better than fewer questions with high-quality human hand-graded evals [S-088].
That third rule is the one teams get backwards. The instinct is five outputs read carefully, usually marked by the person who wrote the prompt, and that is exactly what misses a regression.
For grading there are three methods, and the order of preference sits in the wording. Code-based grading is fastest, most reliable and extremely scalable, but lacks nuance. Grading by a model is fast, flexible and scalable and suits complex judgement, provided you test reliability first. Human grading is most flexible and highest quality, but slow and expensive, and the documentation says to avoid it if possible [S-089].
If a model grades, three things make the verdict usable: a detailed and clear rubric, an output that is empirical or specific such as only “correct” or “incorrect” or a score from 1 to 5, since purely qualitative evaluations are hard to assess quickly and at scale, and a grader model with thinking on [S-090].
Writing criteria and a test set for a task nobody has documented is the actual work here, and it is what an AI consultancy session is for. The prompt takes an afternoon; agreeing on what “good” means takes longer.
How do you write a good prompt?
Clearly, with a reason, with examples, with structure, and with a role. Those are the techniques the documentation names, in the order it uses them. Work through them in that order and measure every change against your test set. No acronym needed.
- Be clear and direct. The golden rule: show your prompt to a colleague with minimal context and ask them to follow it; if they would be confused, Claude will be too [S-091]. So “write a newsletter intro” becomes a brief with the reader, the length, the tone and the one action you want.
- Give the reason behind the instruction. Motivation behind an instruction helps the model understand your goal, because it generalises from the explanation [S-092]. Say why the product name may never be abbreviated, and you stop repairing that mistake every week.
- Give examples. Few-shot examples are one of the most reliable ways to steer output format, tone and structure; keep them relevant and diverse, put each in
<example>tags, and use three to five [S-093]. Three approved product descriptions beat a page about tone of voice, as using Claude for copywriting shows. - Structure the prompt with XML tags. XML tags let Claude parse a prompt that mixes instructions, context, examples and variable inputs, with a consistent, descriptive tag per content type [S-094]. Put the client brief in
<context>and your house rules in<instructions>, and the model stops reading the brief as an instruction. - Set a role in the system prompt. A role focuses Claude’s behaviour and tone for your use case, and even a single sentence makes a difference [S-095]. One line about what the model is reviewing for in your company beats a paragraph of invented persona.
The same living reference also covers chain-of-thought, which is letting the model reason step by step, and prompt chaining [S-096]. Add those once the five above are in place. A team that uses the documented names can hand a prompt over and have it survive, which is half of what a training and workshops day is for.
When is it not a prompt problem?
More often than the search results suggest. Not every success criterion or failing eval is best solved by prompt engineering, and the documentation gives the plain example: latency and cost can sometimes be improved more easily by selecting a different model [S-086].
Next to that, three patterns WeAdapt runs into. None has a wording that fixes it.
- The data is not there. No formulation retrieves a field the model cannot see. That is a connection question, covered in connect AI to your own systems.
- The task needs an action, not a sentence. Looking up an order status, creating a ticket, updating a record: that is an integration with release per operation. A prompt asked to do it describes the action convincingly and changes nothing.
- Nobody wrote the process down. If two colleagues answer the same customer question differently, the prompt is being asked to settle a decision the company never made. Write the rule first.
Does a technique work on every model?
Not automatically. Anthropic publishes a prompting page per model and says that where a technique names a specific model, you should treat it as measured on that model and re-check it against your own evals before applying it to another [S-096]. The separate technique pages are now folded into one living reference, and that is where the documentation says to start [S-096].
So a list copied from a blog post is a hypothesis, not a result. Whether it holds on your model, your task and your data is something only your own test set can tell you.
Why there are no figures about prompt gains here
Because none of them leads back to a primary source. You will read that wording decides a large share of output quality, or that examples add a fixed amount of accuracy. This article does not repeat those numbers. The only one worth quoting in your team is what your own evaluations produced, on your own cases.
Frequently asked questions
Where do you start if none of this exists yet? With the criterion, not the prompt. The guide assumes a clear definition of your success criteria, a way to test against them empirically, and a first draft prompt, and says to establish those first if they are missing [S-085]. One task, one criterion, then grow the set.
Can a model grade its own output? A model can grade output, and the documentation calls that fast, flexible, scalable and suited to complex judgement, provided you test reliability first [S-089]. Give it a detailed rubric, make it return correct or incorrect or a score from 1 to 5, and turn thinking on [S-090].
How many examples should a prompt contain? Three to five works best [S-093]. More is not automatically better. Variation matters more than volume: examples should be relevant to the real case and diverse enough to cover edge cases without teaching the model an unintended pattern [S-093].
How large should a test set be? Larger than feels necessary. The documentation prefers volume over quality: more questions with slightly lower signal automated grading beats fewer questions a person graded by hand [S-088]. Mirror your real task distribution, include the edge cases, and automate the grading [S-088].
Want to work out which criterion fits the task you want to hand over? Book a call. What WeAdapt builds, and how your team runs it afterwards, is in the FAQ.