Structure prompts with tags

Long prompts mix several kinds of material: instructions, reference documents, examples, the user’s input. Wrapping each in a named tag tells the model where one ends and the next begins, and lets your instructions refer to them by name.

You answer questions about our refund policy.

<policy>
Refunds go to the original payment method within 3 working days.
Sale items can be exchanged within 14 days but not refunded.
</policy>

<examples>
<example>
<question>Can I return a sale jacket?</question>
<answer>Sale items can't be refunded, but you can exchange it within 14 days.</answer>
</example>
</examples>

Answer the question in <question> using only <policy>. If <policy> does not cover it, say so.

<question>{{customer_question}}</question>

Why it helps

• No bleeding. The model will not mistake an example answer for the real question, or text in a pasted document for an instruction.
• Precise references. “Using only <policy>” is unambiguous; “using the text above” is not.
• Safer input handling. Putting user-supplied text inside its own tag, and saying that nothing in it is an instruction, is a first line of defence against prompt injection.
• Parsable output. Ask for <answer> and <reasoning> tags and extract them with a simple regex.

Conventions that work

• Use plain, descriptive names: <contract>, <email>, <rules>. There are no special tag names.
• Be consistent: the same name for the same kind of content everywhere in the prompt.
• Nest when content is hierarchical: <documents><document name="a.pdf">…</document></documents>.
• Close every tag. An unclosed tag makes the rest of the prompt look like part of it.

For machine-readable output, prefer structured outputs over tags; use tags when the output is mostly prose with a few parts you need to find.