- 01
- September
"How do you write prompts for Claude that actually work?" — the short answer is write as if you were briefing a brilliant new employee who knows nothing about your organisation. That is not our metaphor; it comes straight out of Anthropic's own prompting documentation. This article walks through seven techniques from the official guide, with ready-to-use prompts for finance, procurement and HR work in Claude.
In one line: The highest-return techniques are not secret phrases. They are three ordinary things: state the output format you want, explain why a constraint exists, and show three to five real examples.
The one rule that tells you if a prompt is good enough
Anthropic's documentation gives a short test: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too."
That rule removes more than half of all prompt problems. The prompts people complain about — "the AI missed the point" — are usually a single line such as "summarise this report", which would produce equally off-target work if handed to a human, because it never says who the summary is for, how long it should be, or which headings it needs.
Seven techniques from the official guide
| Technique | What it does | When to reach for it |
|---|---|---|
| 1. Be clear and direct | State the output format, the length and the constraints | Every time — this is the floor, not an optimisation |
| 2. Explain the why | Give the motivation behind a rule, not only the rule | Whenever there is a prohibition or a compliance requirement |
| 3. Give 3–5 examples | Show correct output, including edge cases | Work that must come back in the same shape every time |
| 4. Structure with XML tags | Separate instructions, data and examples unambiguously | Long prompts with several kinds of content mixed together |
| 5. Set a role | One sentence of role framing changes tone and rigour | Work needing a specific professional lens |
| 6. Long documents first, question last | Put source material above the instruction | Document-heavy work, roughly 20K tokens and up |
| 7. Quote before concluding | Have Claude extract relevant passages first, then analyse | Anything that has to be traceable back to a source |
Techniques 1–2: clarity, and the reason behind the rule
The documentation's own illustration is hard to improve on. Instead of writing "NEVER use ellipses", write "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." The difference matters because once the model knows the reason, it generalises the principle to cases you never enumerated.
The guide also stresses that above-and-beyond output has to be requested explicitly. Its example contrasts "Create an analytics dashboard" with "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation." One appended line changes the entire scope of what comes back.
| Task | Weaker prompt | Stronger prompt |
|---|---|---|
| Finance | "Take a look at this trial balance." | "Review the attached trial balance. Flag every account whose balance moved more than 20% from last month. Return a four-column table: account code, account name, variance, plausible cause. Where the data is insufficient to state a cause, say which document you would need instead." |
| Procurement | "Draft a TOR for me." | "Draft terms of reference for a purchase of 30 desktop computers, following the heading structure in the attached sample. Do not name any brand or model, because our procurement rules prohibit locking specifications; express requirements as minimum characteristics instead. Maximum two pages." |
| HR | "Summarise the leave policy for staff." | "Summarise the attached leave regulation for new joiners. One page, plain language rather than regulatory wording, organised by leave type, with the source clause number in brackets after each heading so it stays verifiable." |
Notice the shared pattern: every prompt in the right-hand column names four things — the task, the shape of the output, the prohibition, and what to do when the data is insufficient. The fourth is the one most often left out, and the one that most directly prevents guessing.
Techniques 3–5: examples, tags and roles
Examples (few-shot or multishot prompting) are described in the guide as one of the most reliable ways to steer output format, tone and structure. The recommendation is three to five examples, chosen to mirror the real task, diverse enough to cover edge cases, and wrapped in <example> tags so they are clearly distinguishable from instructions.
XML tags are the organising tool that pays off as soon as a prompt gets long, because they separate instructions, data and examples without ambiguity. Use descriptive tag names and keep them consistent across prompts:
<instructions>
Check the attached purchase requisition against our rules.
Answer as a pass / fail list with a one-line reason for each item.
If a field needed for the check is missing, say what is missing. Do not assume.
</instructions>
<checklist>
1. Document number and date present
2. Funding source identified
3. Approver matches the value threshold
4. At least one supplier quotation attached
</checklist>
<document>
[paste the requisition here]
</document>On roles, the guide notes that even a single sentence in the system prompt shifts behaviour measurably: "you are an internal auditor who insists on supporting evidence" produces noticeably more cautious answers than "you are a helpful assistant". For people working through the web interface, the best place to put that role is the custom-instructions field of a Project, so it applies to every chat in the room without being retyped.
Techniques 6–7: working with long documents
These two apply only to document-heavy work, but they produce the clearest gains of the seven.
Order matters more than people expect. The guide recommends placing long documents above the query and instructions, and notes that in testing, putting the question at the end improved response quality by up to 30 percent, particularly on complex multi-document inputs. If you habitually attach files and then type a short question underneath, you have been doing this correctly by accident.
Ask for quotes before conclusions. This technique instructs Claude to extract the relevant passages first, then reason from that extracted set. The benefit is twofold: the model concentrates on the relevant material, and — more valuable in an enterprise setting — you get the provenance attached, so any conclusion can be traced back to a line in the source.
[paste the full documents here first]
Based on the documents above:
1. First extract every passage relating to warranty terms into <quotes> tags.
2. Then summarise them as a comparison table across the bidders.
3. If a point is not covered by the passages in step 1, state that it was not found.Why technique 7 matters for audit and public-sector work: an answer that carries its supporting quotations can be verified in ten seconds. A free-floating summary has to be checked by re-reading the whole document, which means no time was saved at all.
A prompt template the whole organisation can reuse
Rather than leaving every employee to invent prompts, organisations that get value from AI usually maintain five to ten shared templates. This skeleton covers most document work:
Role: [e.g. a procurement officer who applies the rules strictly]
Task: [numbered steps if the order matters]
Output: [format and length, e.g. four-column table, max one page]
Do not: [e.g. name brands; invent new formulas]
If data is insufficient: say what is missing. Do not assume.
<document>
[content]
</document>Four traps that waste time
| Trap | What to do instead |
|---|---|
| Hunting for "magic words" | There are none. The official guide is about clarity — brief the model as you would brief a person |
| Writing long prompts just in case | Long and vague beats short and clear only in word count. What should be long is the examples and the constraints |
| Expecting first-pass perfection | Two or three iterations is normal; the fastest route is naming exactly what was wrong and asking for that part only |
| Packing many steps into one prompt | Chain the prompts — one goal per turn, so each step can be checked before the next |
Back-office reality: prompting does not fix bad data
One limit deserves to be said plainly. The best prompt in the world cannot rescue a wrong input. If the stock report you attach does not match what is physically in the warehouse, the answer will be wrong — elegantly, confidently and in your preferred table format.
The division we recommend to clients is constant: let the ERP system own the numbers, and let Claude read, structure, cross-check and draft from those numbers. Pointing AI at data still scattered across multiple spreadsheet versions accelerates an existing problem rather than solving it — the same argument made in passing Excel files around leaks data without anyone noticing.
Teams ready to move from individual prompting to an organisational standard should look at packaging proven prompts as Claude Skills, so everyone invokes the same version instead of pasting text to each other in chat.
Conclusion
None of the seven techniques in Anthropic's guide is magic. Each is simply good delegation, and each would work on a human just as well — be specific, give the reason, show examples, organise the input, set the role, put documents before the question, and always ask for evidence.
If you adopt only one, add this closing line to every prompt: "if the data is insufficient, say what is missing and do not assume." It is the single ten-second change that most reliably turns an answer from plausible-looking into usable.
A good prompt is not about knowing secret words. It is about describing the job clearly enough that someone unfamiliar with it could still do it.
- The Saeree ERP team
References
- Anthropic — Prompting best practices (checked 1 Sep 2026)
- Anthropic — Prompt engineering overview
- Anthropic — Prompt engineering interactive tutorial (GitHub)
Want your team prompting to one standard?
We help build prompt templates around each department's real work, train the team, and supply Claude licences with full Thai invoicing.
Get advice / request a quoteTel 02-347-7730 | sale@grandlinux.com
