XML Prompts: Structure Instructions, Examples, and Source Text

XML-style tags in prompts — angle-bracket markers like <instructions>, <example>, and <source> — help an AI model distinguish between different kinds of content in a long prompt. They are not a protocol the model must follow; they are a formatting choice that makes the structure of a complex prompt clearer to a model trained to notice them. Tools like fenbs let you save the prompt patterns that use this structure reliably, so every session draws from tested templates rather than rewritten variations.

This guide explains how XML tags work in prompts, where they genuinely help, and what they cannot do — including the important limit that a model trained to process XML-tagged content can still be misled if injected text reuses the same tags.

What XML tags do in a prompt

When you include <instructions>...</instructions> in a prompt, you are wrapping a section of text in a labeled container. A model that has seen this pattern many times during training learns to treat text inside that tag as a different category from text outside it. This makes it easier for the model to distinguish between your instructions and the content you want it to process.

Without tags, a long prompt can become ambiguous. If you paste a source document inside a prompt and then add instructions after it, the model may not clearly separate "here is what to read" from "here is what to do." Tags make that boundary explicit. The model is more likely to apply instructions to content rather than treating them as part of the content.

Tags also improve your prompts as documents. A prompt template with clearly labeled sections is easier to maintain and share than a paragraph of instructions with examples and source material mixed together. The tags serve you as a writer of prompts as much as they serve the model processing them.

Common tags and when to use them

There is no official standard for prompt XML tags. Use names that are clear and consistent. The patterns below are widely used because they map to natural categories in a complex prompt.

• <instructions> or <task>: the specific task you want the model to perform.
• <context> or <background>: relevant background the model needs but that is not the material to process.
• <source> or <document>: the text you want the model to work from.
• <example> or <examples>: demonstrations of the input-output pattern you want.
• <format> or <output_format>: how you want the response structured.
• <rules> or <constraints>: limits the model must respect in its response.

<context>
I am preparing a summary for a client who is not technical. They have read the background documents but not the latest update.
</context>

<source>
[paste the text to summarize here]
</source>

<instructions>
Summarize the key changes in this update in plain language. Explain any technical term the first time you use it.
</instructions>

<format>
- Use bullet points
- Keep each point to one sentence
- Do not exceed 200 words
</format>

<rules>
- Use only what is in the source above
- Do not add context from your training
- If the source does not address a key question, say so
</rules>

Notice that the source comes before the instructions in this template. That ordering is deliberate for long source documents: the model processes more of the source before reading the task, which can help it attend to the full document rather than the tail of a long context. For short prompts, ordering matters less.

Where XML tags genuinely help

XML tags produce the most benefit in long, complex prompts that mix several kinds of content. If your prompt has instructions, background, source material, and examples all in one message, tags prevent the model from confusing which part is which.

Tags also help when you want to include multiple examples without the model blending them. Wrapping each example in its own <example> tag makes the boundary between examples clear. Similarly, if you want the model to treat two documents differently — one as background context, one as the material to analyze — separate tags make that distinction explicit.

Short, simple prompts do not need tags. A single-question prompt with no embedded content is clear without structural markers. Tags add value when complexity would otherwise create ambiguity — not as a general best practice for every prompt.

What XML tags cannot do

Tags do not guarantee that a model will follow the instructions inside them. A model can misread, ignore, or partially follow instructions regardless of their formatting. Tags reduce the chance of misreading by making structure clear, but they do not enforce compliance in the way a programming language enforces syntax.

Tags also do not protect against prompt injection — a specific security concern in automated pipelines where untrusted input is included in a prompt. If a malicious source document contains text formatted to look like instructions or override tags, the model may process that injected text as real instructions. Whenever you are including external content in a prompt, be aware that content formatted as instructions can interfere with your actual instructions, regardless of whether you use tags.

For a thorough look at prompt injection risks in automated settings, see indirect prompt injection. For context-engineering patterns that shape what the model sees beyond individual prompts, see context engineering vs prompt engineering.

Building reusable prompt templates with XML tags

XML-tagged prompts lend themselves naturally to templates: you write the structure once, with placeholders inside the tags, and fill in the content each time you use the template. A template is more consistent than a prompt rewritten from memory — the structure stays the same, only the content changes.

<context>
[describe the reader, the purpose of this analysis, and any relevant background]
</context>

<source>
[paste the content to analyze]
</source>

<task>
[state the specific question or analysis request]
</task>

<format>
[describe the output format: length, structure, style]
</format>

<rules>
- Only use what is in the source above
- Flag any gap between the source and the task
- List assumptions at the end
</rules>

How to do this with fenbs

1. Create a free account and add a project for the type of work you use these prompts for.
2. Write your reusable prompt templates using XML tags for structure. Test each one with two or three examples before saving it.
3. Save each tested template as a Skill in fenbs with a clear title, the tag structure it uses, and a note on what content goes in each tag.
4. Add any formatting rules or output requirements that apply to all prompts in this project as Decisions, so they carry over to every session.
5. Connect your AI app over MCP from Integrations. Ask the assistant to list your Skills before starting a task, so it can read the right template rather than you pasting it.

When to use other prompt structuring approaches

XML tags are one tool for structuring prompts. Other approaches work well in different situations. Numbered lists work for sequential steps. Markdown headers work for prompts shared in tools that render markdown. Plain prose works for short, simple prompts that do not need structure. Choose the approach that makes the prompt clearest to read and maintain, not the one that looks most formal.

See system prompt examples for a collection of complete prompt patterns and prompt engineering for the broader principles behind writing prompts that hold up across different models and sessions.