How to write a prompt that works
Four things every decent prompt carries, drawn from the same before and after example I use in sessions, and set against the techniques Anthropic publishes itself.
Most advice on how to write Claude prompts arrives as a template. Fill in the blanks, paste it, admire the result. I will save you the download: a template fails the moment your task differs from the one it was written for, which is usually the first time you use it. What holds up is four things, asked every time, in whatever order suits you.
Name the voice, and name who is reading
A request with no voice attached gets you the average of everything ever written on the subject, which reads like a brochure produced by committee. "You are writing as our COO: dry wit, plain English, no hashtags" narrows the field enormously, and costs you nine words.
Naming the audience does as much work again. "For operations leads who are tired of AI hype" tells Claude what to leave out, and leaving out is the more valuable half of writing. Anthropic calls this role prompting and lists it among its core techniques, alongside clarity and examples.
Say what shape it should be, and how long
"Not too long" means nothing. About 120 words means something. "Lead with the problem it removes rather than the features, and end on a question" is a structure, and structure is where most weak output goes wrong. The sentences were fine, the thing was built in the wrong order.
Length matters more than people expect, because without a number you get the model's default register, which tends towards the thorough and the slightly padded.
A useful test before you send anything: could a capable colleague produce roughly the right thing from what you have written, without coming back to ask you a question? Wherever they would have to guess is precisely where Claude will quietly substitute an assumption of its own.
Show it one example, and skip the developer techniques
Examples sit second on Anthropic's own list, ahead of everything technical. Two past posts pasted in beats three paragraphs describing your tone, every time, because tone is easier to demonstrate than to define.
One caution. More material in the conversation is not automatically better material, whatever the size of the window it is sitting in. Two good examples beat nine mediocre ones, and what a context window is and is not is a separate question from how well you have filled it.
Anthropic's documentation orders its techniques as clarity, examples, XML structuring, role prompting, thinking, then prompt chaining. Translated: say precisely what you want; show it one; separate the brief from the raw material with obvious labels, since plain headings such as BRIEF and SOURCE MATERIAL work as well as tags for most people; tell it whose voice to use; ask it to reason before answering; and split a long job into steps.
The last two mostly matter to developers building something repeatable. If you are drafting a paper before Thursday, you can ignore them without loss.
Where to see the difference
The before and after on my homepage is this whole article in one drag: the same request written twice, with the four elements marked in the margin. Where the results in one team vary wildly from desk to desk, you are looking at a gap in habit, not in software.
So write the next one long. Name the voice, name the reader, set the shape and the length, paste in something to match, and accept that it costs you four minutes at the front.
None of this is difficult. It is the part everybody skips, because writing a proper brief feels like more work than writing a bad one and finding out thirty seconds later that it was.