Clarity, examples and XML structure
Everything in this lesson lives under General principles on the consolidated page, and it is the highest-frequency material in the whole prompt-engineering domain. It is also the part people think they already know, which is why it is worth being precise about.
Be clear and direct, and stop hedging
The single most common defect in a real prompt is politeness. You write “it would be helpful if you could perhaps summarise” when you mean “summarise”.
Treat the model like a new colleague with no context and excellent reading comprehension. They will do exactly what you asked. They will not do the thing you meant but did not write down. Vague instructions do not produce cautious output, they produce confident output aimed at the wrong target.
The paired principle is add context: tell it what the output is for, who reads it, and what happens next. “Summarise this” and “summarise this into three bullets a support agent will read while on a call” are different tasks, and only one of them is specified.
Examples: 3 to 5, and wrap them properly
The number is 3 to 5. Memorise it, because it is exactly the sort of concrete figure a multiple-choice question is built from.
The structure is nested: each example goes in its own <example> element, and all of them sit inside one <examples> wrapper.
<examples>
<example>
<input>Ticket: card declined twice, customer furious</input>
<output>{"category": "billing", "severity": "high"}</output>
</example>
<example>
<input>Ticket: how do I change my avatar</input>
<output>{"category": "account", "severity": "low"}</output>
</example>
</examples>Pick examples that cover your edge cases, not three variations of the easy case. Three examples that all look the same teach the model one thing three times. The useful way to choose them is the way you choose test cases: the boundary, the ambiguous one, the one that broke last time.
Structure with XML tags
The recommended tags are <instructions>, <context> and <input>. Those three names come straight from the docs and they are worth using verbatim rather than inventing your own vocabulary.
Here is why the format matters and it is a parsing argument, not an aesthetic one. A markdown heading is an opening delimiter with no closing delimiter. The parser infers the end of the section from the start of the next one, which works right up until the content you interpolated contains a ## of its own, at which point your carefully laid-out prompt silently reshapes and nothing errors.
That last point is not just tidiness. It is the seam where prompt injection gets in, which is why we come back to delimiting untrusted content in Module 4.
Roles, and knowing what the model knows
Give Claude a role when the role changes the output. “You are a compliance reviewer” genuinely shifts what gets flagged. “You are a helpful assistant” shifts nothing and costs you tokens for the privilege.
Model self-knowledge is the quieter principle and it matters for accuracy. The model has a training cutoff and it does not know your private systems. If a task depends on current facts or internal state, that material has to arrive in the context, not be assumed present in the weights. A prompt that asks the model to recall something it was never given produces a fluent guess, and a fluent guess is the most expensive kind of wrong.
Try it yourself
How many examples
You are writing a few-shot classification prompt. The docs give a specific range. Which is it?
Show answer
Correct answer: C — 3 to 5
The documented guidance is 3 to 5 examples. Option 4 is the tempting one because more examples genuinely does help up to a point, and people reason that a 1M window means the point is far away. It is not a context-size question: the guidance is about the examples doing their job of pinning down format and edge cases, which 3 to 5 does. Cramming forty in costs tokens and adds noise without adding signal.
Three ways to ask for the same thing
Three candidate instructions for one job. Exactly one of them matches the documented guidance.
A: It would be helpful if you could perhaps summarise this where appropriate.
B: Summarise this.
C: Summarise this into three bullets that a support agent will read aloud
while on a call with the customer.Which one should you ship, and for what reason?
Show answer
Correct answer: B — C, because it is direct and it also states what the output is for and who reads it
Be clear and direct is one principle and add context is its pair; C satisfies both. Option 3 is the genuinely tempting one, because B is maximally direct and directness is the headline advice, so it looks like the pure form of the rule. It is under-specified: summarise this into what, for whom, at what length. Option 1 is the misconception the lesson attacks head on, since vague instructions do not produce cautious output, they produce confident output aimed at the wrong target.
The three recommended tags
Use the documented names verbatim rather than your own vocabulary. That is the point of this card: the specific words, not the general idea of tagging.
Which XML tags does the documentation recommend for prompt structure, and what does each contain?
Reveal answer
instructions for what you want done, context for the background material the model needs, and input for the actual thing being operated on this call. Examples get their own nesting: individual example elements wrapped inside an examples element.
Why tags beat headings
The reason is structural, not stylistic, and it is the same reason that returns in Module 4 as a security argument. If your answer is only that tags look tidier, you have the weaker half.
Why does XML tagging beat markdown headings for prompt structure?
Reveal answer
Tags have unambiguous open and close boundaries, so the model can tell exactly where a section ends. A markdown heading only says where a section starts; its end is inferred from the next heading, which breaks the moment your injected content contains a heading of its own. Tags also survive user content that happens to contain markdown, and they give you something to reference by name in your instructions.
Spot the bug in this envelope
A few-shot classification prompt, reduced to its structure. The tags are all valid XML and it parses fine.
<instructions>Classify the ticket.</instructions>
<examples>
<input>Ticket: card declined twice, customer furious</input>
<output>{"category": "billing", "severity": "high"}</output>
</examples>
<examples>
<input>Ticket: how do I change my avatar</input>
<output>{"category": "account", "severity": "low"}</output>
</examples>What has gone wrong against the documented structure?
Show answer
Correct answer: D — Each example needs its own example element, and all of them belong inside a single examples wrapper
The documented envelope is one examples wrapper containing one example element per case. Here the per-case element is missing entirely and the wrapper has been repeated in its place. Option 1 is the tempting one, and it is tempting for a good reason: this is well-formed XML, it reads clearly to a human, and nothing in your toolchain will ever complain. The cost is that the model has no element marking where one example ends and the next begins, which is precisely the boundary the structure exists to supply.
Retag one prompt
Small, offline, ten minutes. No account needed. This is the exercise most likely to improve something you ship this week rather than something you sit an exam on.
- Open a scratch file and paste in any prompt you have written that is longer than about ten lines.
- Wrap the ask in instructions tags, the background in context tags, and the per-call payload in input tags.
- Add three examples, each in its own example element, all nested inside one examples element.
- Read it back and find every place your original relied on the model inferring a boundary you never marked.