Writing effective prompts

The golden rule

Anthropic states one test above all others: show your prompt to a colleague with minimal context on the task and ask them to follow it. If they would be confused, Claude will be too. That single sentence resolves most prompting arguments. It is not about magic words or clever phrasing — it is about whether a competent stranger could do the job from your instructions alone.

Apply it literally. Read your prompt back and ask what a stranger would have to invent. If they would have to guess the audience, the length, the time period, the tone, or which of four attached files matters, so does Claude — and it will guess plausibly rather than ask. The documentation puts the same point positively: the more precisely you explain what you want, the better the result.

Write a summary of the attached
customer feedback.

For our Head of Product, who has 10
minutes before a roadmap meeting.

Using only the attached 60 Q2 support
tickets, write:

1. The five most common complaints,
   ranked by frequency, with a count.
2. One customer quote per complaint.
3. A short "what we don't know yet"
   section.

Under 400 words, plain prose. Leave
out any theme appearing in fewer than
three tickets, and say so.

The five things a business prompt should carry

You do not need a template for every message, but when an output matters it is worth checking that five things are present. Most weak prompts are missing three of them.

Two further habits lift results noticeably. The first is explaining why. Anthropic’s guidance contrasts a bare instruction with the same instruction plus its motivation — “never use ellipses” against “your response will be read aloud by a text-to-speech engine, so never use ellipses since the engine will not know how to pronounce them” — and notes that Claude is smart enough to generalise from the explanation. Tell Claude that the memo goes to a regulator and it will make a hundred small choices you never spelled out.

The second is sequencing. Where the order or the completeness of steps matters, the documentation recommends giving instructions as numbered steps or bullet points. A prompt that says “compare the vendors and recommend one” invites a general essay; “1. Score each vendor against the five criteria. 2. Show the scores in a table. 3. Recommend one and give the two strongest reasons against your own recommendation.” produces the document you actually wanted.

Show, don’t only tell

When you care about format, tone or structure, an example beats a description. Anthropic calls examples one of the most reliable ways to steer Claude’s output format, tone and structure, and recommends including three to five of them for best results. Good examples are relevant — they mirror your actual use case; diverse — they cover edge cases so Claude does not pick up an unintended pattern; and clearly separated from your instructions.

Separation is the part people skip. The documentation recommends wrapping examples in tags — <example> for one, <examples> around several — so Claude can tell a demonstration from an instruction. You do not need to be a developer to do this in the Claude apps: typing <example> and </example> around a sample is exactly the technique, and the same trick works for anything you paste. Label a pasted block <policy>, <transcript> or <last_month_report> and you can then refer to it by name in the rest of your prompt. Anthropic’s long-context guidance adds one more placement rule for large inputs: put the long documents at the top and your actual question at the end — in their tests this improves quality by up to thirty percent on complex multi-document inputs.

Summarise each sales call in a
consistent, professional format.

Summarise each call in exactly the
format shown below.

<example>
Account: Northwind Traders
Stage: Evaluation
Discussed: pricing tiers, data
  residency
Blocker: needs EU hosting confirmed
Next step: send hosting one-pager
  by 14 Mar (Anika)
</example>

Now do the same for each call in the
<transcripts> block above.

Say what you do want

A recurring piece of Anthropic guidance is to tell Claude what to do rather than what not to do. “Do not use markdown” is weaker than “write in flowing prose paragraphs”; “don’t be too formal” is weaker than “write as you would to a colleague you know well”. A negative instruction leaves the target undefined, and it makes the unwanted thing the most prominent idea in the prompt. Positive instructions are also easier to check afterwards: you can look at the output and see whether prose paragraphs happened.

The same logic applies to effort. Current models are described as following instructions precisely and doing what was asked rather than volunteering extras. If you want counter-arguments, risks, or a second option, ask for them. The documentation’s own illustration is a dashboard request: “create an analytics dashboard” versus “create an analytics dashboard, include as many relevant features and interactions as possible, go beyond the basics”. The second gets more because it asked for more.

One closing caution. A complete brief makes a good output far more likely; it does not make the output true. Everything in this lesson raises the quality of the draft, and none of it removes the need to check figures and claims against their sources before the work leaves your desk — which is Domain 2, the largest domain on this exam.

Traps the wrong answers are built from

You should now be able to

• Test a prompt with the golden rule — would a colleague with minimal context be confused?
• Check a draft prompt for task, audience, source, format and constraints before sending it.
• Supply motivation behind an instruction so Claude can generalise to cases you did not list.
• Use three to five labelled examples to fix format and tone instead of describing them.
• Structure a long input with labelled sections and put the question at the end.
• Rewrite negative instructions as positive, checkable ones.