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.

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.

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.