Short answer
Anthropic's engineers treat a prompt as a brief for a brilliant new employee with no context: state the task plainly, explain why, show three to five real examples, give the model permission to say it is unsure, and then read the outputs and iterate. Their published guidance favours clear instructions over personas, puts long documents before the question, tells the model what to do rather than what not to do, and keeps prompts to the smallest set of high-signal instructions that reliably works.
Most prompting advice online is a list of magic phrases. Anthropic's is different, partly because the company publishes the guidance its own engineers use. We read the current best-practices reference, the 2026 prompt engineering post, the engineering essays on context engineering and building effective agents, the Claude Code best practices used by Anthropic's internal teams, and the company's recorded prompt engineering roundtable. What follows is the method that runs through all of them, with the developer detail removed.
1. Write for a brilliant new employee with no context
This is the frame Anthropic's guide uses word for word: think of Claude as a brilliant but new employee who lacks context on your norms and workflows. Its "golden rule" follows: show your prompt to a colleague with minimal context and ask them to follow it. If they would be confused, so will the model. In the roundtable, Anthropic's researcher Amanda Askell describes the same discipline as externalising everything you know about the task rather than assuming shared context.
For a business: the reason your first prompt for invoice extraction failed is probably that it assumed the model knew which of your suppliers bill in advance, or what "the usual project code" means. Write those things down.
2. Say why
Anthropic's example is memorable. "Never use ellipses" works less well than "your response will be read aloud by a text-to-speech engine, so never use ellipses, since it will not know how to pronounce them." The guide's comment: Claude is smart enough to generalise from the explanation. A reason lets the model make the right call in the cases you did not anticipate.
3. Examples beat adjectives
The guide calls examples "one of the most reliable ways to steer" output, recommends three to five, and asks that they be relevant, diverse and clearly wrapped as examples. Anthropic's context-engineering essay puts it as: for a model, examples are the pictures worth a thousand words. The 2026 post adds a warning: current models pay very close attention to details in examples, so a lazy example teaches a lazy pattern.
For a business: instead of "write in our friendly professional tone", paste three replies your best team member actually sent.
4. Give it permission to be unsure
Every source says this in some form. The 2026 post's example: "If the data is insufficient to draw conclusions, say so rather than speculating." In the roundtable, Alex Albert describes giving the model an explicit out for edge cases, such as marking a response as unsure, which improves reliability and makes the failures easy to find. Anthropic's agent guidance goes further: when a task is broken or impossible, the model should ask or stop rather than pursue "increasingly questionable alternatives".
For a business: every automation prompt we write ends with a version of "if you cannot complete this cleanly, stop and flag it for a person." It is the cheapest guardrail there is.
5. Read the outputs
Zack Witten, one of Anthropic's prompt engineers, says in the roundtable that if you are not reading the model's outputs you may not even notice the mistake it is making. David Hershey adds that people test beautiful, structured inputs and never account for how messy real users are. Askell's list of what makes a good prompt engineer is short: clear communication, the ability to iterate, and thinking about the ways a prompt might go wrong.
For a business: collect twenty real inputs, including the ugly ones, and read all twenty outputs before you trust the workflow. Then read a sample every week.
6. Be direct; personas are optional
A one-sentence role in the system prompt can help focus tone, and Anthropic's reference still shows one. But the 2026 post lists role prompting among the techniques that are "less necessary with modern models", and Askell has argued for simply telling the model the real task rather than pretending it is something else. Explicit instructions win.
7. Structure long inputs, and put the question last
When a prompt includes long documents, Anthropic's guide says to place them at the top and the question at the end, noting that this improved response quality by up to 30% in its tests on complex multi-document inputs. Wrap different kinds of content, such as instructions, context and the input, in clearly named sections so the model does not confuse one for another.
8. Say what to do, not what not to do
The 2026 post states it plainly: tell the AI what to do instead of what not to do. A list of prohibitions leaves the model guessing at the positive behaviour. "Reply in two short paragraphs, then a bulleted list of next steps" beats "do not write long replies".
9. Find the right altitude
Anthropic's context-engineering essay describes two failure modes for system prompts: hard-coding brittle if-then logic, and vague guidance that assumes shared context. The target is "specific enough to guide behavior effectively, yet flexible enough to provide the model with strong heuristics", and the overall principle is to find the smallest set of high-signal instructions that reliably produces the outcome. The 2026 post agrees: the best prompt is not the longest, it is the one that achieves the goal with the minimum necessary structure.
10. Put safety in the prompt, and outside it
Anthropic's reference includes a sample instruction it recommends for agents: consider the reversibility and impact of actions, take local reversible actions freely, and ask before anything destructive, hard to reverse, or visible to others. That matches how we build. The prompt asks for caution; the approval step outside the model guarantees it.
11. Give the model a way to check its own work
The Claude Code guide's first recommendation is to give the model a check it can run: a test, a build, a comparison. Without one, "looks done" is the only signal. In business terms, an agent that extracts invoice totals should also be told to compare its total against the line items and flag a mismatch, rather than hoping a person notices.
12. Start simple
Anthropic's agents essay is blunt: add complexity only when it demonstrably improves outcomes, and begin with a single well-crafted call before you build chains, routers or autonomous agents. Most business workflows never need more than one or two steps.
A brief you can copy
Put together, an internal prompt for, say, triaging inbound inquiries looks like a short brief rather than a spell:
- Task: classify each inbound message as sales, support, billing or other, and draft a first reply for sales and support.
- Why: the sales team responds within an hour to qualified leads; support has a separate queue; billing must never receive an automated reply.
- Context: what the company sells, who the customers are, the three products by name, and what "qualified" means.
- Examples: three real messages with the correct category and the reply a person actually sent.
- Format: category on the first line, draft below, nothing else.
- The out: if the message is ambiguous, in a language you are not confident in, or mentions a legal or safety issue, output "unsure" and stop.
Then run twenty real messages through it, read every output, and fix the brief before you fix anything else. That is, as far as we can tell from what they publish, how the people who build the model do it.
Frequently asked questions
Do I need to tell the AI to act as an expert?
Less than you might think. Anthropic's current guidance says a one-line role in the system prompt can help focus tone, but that explicit instructions usually beat personas. Its researchers have argued for simply telling the model what you actually want and why.
How many examples should a prompt include?
Anthropic recommends three to five, chosen to be relevant, diverse and clearly marked as examples. Its engineers note that current models pay very close attention to examples, so an example that contradicts your instructions will win.
What is the single most useful habit?
Read the outputs. Anthropic's prompt engineers say the most common failure is people who test polished inputs, never look at real results, and so never notice the mistake the model is making on messy real-world data.
Does any of this apply to ChatGPT or Gemini?
Almost all of it. The advice is about clear communication, examples, structure and honesty about uncertainty. A few details such as tag names are Claude-specific; the method is not.
