Claude XML tags: separate sources, examples and tasks

Claude XML tags separate the parts of a prompt: source material, instructions, examples and the requested output. Use descriptive opening and closing tags when those boundaries would otherwise be unclear. The tags organise the input; they do not verify its facts, create a security boundary or guarantee that Claude will follow every instruction.

The templates below are original examples for ordinary document and writing tasks. They are not measured test results. Use material you are permitted to share and check the answer against the source.

On this page

When tags earn their place

A short request such as “Suggest three names for a fictional cafe” does not need elaborate markup. Tags are more useful when the prompt mixes a document with a task, includes several sources or contains examples that should not be mistaken for new input.

Anthropic’s XML lesson describes tags as delimiters. You can choose names that explain the content rather than looking for a special vocabulary.

Before adding tags, identify the boundary that is causing trouble. Is Claude rewriting the example instead of the draft? Is it treating a sentence inside a document as part of the user’s task? Is it mixing two source versions? Name those parts explicitly.

Start with one source and one task

This template keeps a policy excerpt apart from the request about it:

<policy_excerpt>
[Paste the policy text you are allowed to share.]
</policy_excerpt>

<task>
Explain the cancellation terms in the policy_excerpt.
Use only the supplied text.
For each stated rule, include a short supporting quotation.
If the excerpt does not answer a question, say that it is not stated.
</task>

<output_format>
Use the headings Stated rules and Questions left open.
</output_format>

Replace the bracketed text before sending. Keep the same tag name when referring to the source in the instructions.

Then compare each quotation with the original. A well-separated prompt still cannot establish whether the pasted policy is complete or current. Add the document’s date or version when that distinction matters to the task.

For broader advice on task, context and constraints, use the Claude prompting guide.

Label multiple documents

When two documents share the same subject, give each a stable identifier. In this original template, the task is to compare two event policies:

<documents>
  <document id="A">
    <source_name>[First policy and version]</source_name>
    <content>[First policy text]</content>
  </document>
  <document id="B">
    <source_name>[Second policy and version]</source_name>
    <content>[Second policy text]</content>
  </document>
</documents>

<task>
Compare the stated cancellation deadlines.
Return Policy ID, Stated deadline and Supporting quotation.
Do not infer a deadline from a document that omits it.
</task>

The identifiers make the requested comparison easier to inspect. They are labels supplied by the user, not citations to documents Claude independently retrieved.

Check that every result points to the correct version. Two files with similar names may describe different dates or audiences. Tags help you name that distinction; they do not resolve it for you.

Keep examples separate from new input

An example teaches a pattern. The current input is the material to process. Give them separate containers:

<example>
  <message>The parcel arrives on 12 November.</message>
  <answer>Delivery date: 12 November</answer>
</example>

<example>
  <message>The parcel ships on 12 November.</message>
  <answer>Delivery date: Not stated</answer>
</example>

<input_messages>
[Paste the new messages.]
</input_messages>

<task>
Extract the stated delivery date from each input message.
Follow the distinction shown in the examples.
</task>

The second example defines a useful edge case: dispatch is not delivery. The labels alone would not supply that rule. You still need an instruction or example that explains the distinction.

The few-shot prompting guide goes deeper into choosing examples rather than merely adding more of them.

Make the structure easy to maintain

Use a small vocabulary of names that describe the actual job. A prompt with several unrelated sections called “data” becomes hard for a person to maintain too.

Check opening and closing tags, indentation and references to names. If you rename a source block, update the task that refers to it. These are readability checks, not a claim that everyday prompts require a formal XML parser.

Nest containers when there is a real hierarchy, as in several documents inside a document collection. Avoid layers that add no distinction. An instruction can remain an ordinary sentence outside a tag if the boundary is already clear.

Review the answer by the task’s criteria

Start with a representative input and inspect the result. Did it use the intended source? Did it preserve missing information? Did it apply the example’s rule to the new material?

Change the part of the prompt responsible for the mismatch. If the problem is an unclear output format, more source tags may not help. If the source omits the answer, adding a more forceful instruction will not supply the missing fact.

Keep the limits explicit. Tags do not make untrusted material safe, grant access to private files or override the product’s rules. For reusable instructions versus the current request, see system prompts.