Structure with XML tags

You have a clear, specific prompt scoring 7.86. Now imagine the athlete-info block is not four lines but forty, and the prompt also includes a sample meal plan, a list of available ingredients, and some pricing data. Everything starts running together. Is that paragraph the user's restrictions or the example output? This is where XML tags earn their keep.

Why structure matters

Claude parses your prompt as a single stream of text. When the stream is short and has obvious sections ("athlete info: ... Generate a meal plan..."), that's fine. When the stream is long and mixes instructions with data with examples with constraints, the boundaries get blurry — and blurry boundaries produce output that is sometimes exactly right and sometimes oddly confused about which piece of input was which.

XML tags give you explicit, unambiguous boundaries between sections of the prompt. Claude treats a tagged region as a distinct unit: "this is the athlete information," "this is the code to review," "this is the documentation."

Here's the problem without tags:

Analyse these sales records and identify the three biggest opportunities. Q1: 450k... Q2: 512k... [20 pages of data] ...make the recommendations actionable.

Where do the instructions end and the data begin? Where do the data end and the second set of instructions begin? Claude can usually figure it out. "Usually" is not a word you want in production.

With tags:

Analyse the sales records below and identify the three biggest opportunities.

<sales_records>
Q1: 450k
Q2: 512k
...
</sales_records>

Make the recommendations actionable.

Now the structure is self-documenting. Instructions are instructions, data is data, and the two can't be confused.

Use descriptive custom tag names

The tag names don't need to be real XML — they just need to be descriptive. Claude reads them as semantic hints about what the content is. Specific beats generic every time:

• <sales_records> beats <data>
• <athlete_information> beats <input>
• <my_code> and <docs> beat <code1> and <code2>
• <customer_message> beats <text>

The more specific the tag, the more Claude can use the tag name itself as a cue about what to do with the content. <docs> with documentation inside it is easy for the model to interpret; <section> is a waste of the structure.

A more dramatic example: code + docs

Say you want Claude to debug a function using some provided documentation. Without tags:

Debug this function and explain any issues using the documentation provided. def process_order(order): ... The process_order function is called by... Check for error handling problems.

It's nearly impossible to tell where the code ends and the documentation begins. Claude will try, and it may succeed, but you're making its job unnecessarily hard.

With tags:

Debug the function below using the provided documentation. Check for error-handling problems.

<my_code>
def process_order(order):
    ...
</my_code>

<docs>
The process_order function is called by the checkout flow...
</docs>

Now there's no ambiguity at all. The two content blocks are clearly separated, and Claude can reference them independently ("in my_code, line 3...").

Apply it to the meal plan prompt

The athlete information in the meal plan prompt is a small block, so the improvement here is more about hygiene than dramatic score gains. Still worth doing:

Generate a one-day meal plan for an athlete that meets their dietary restrictions.

<athlete_information>
- Height: {prompt_inputs["height"]}
- Weight: {prompt_inputs["weight"]}
- Goal: {prompt_inputs["goal"]}
- Dietary restrictions: {prompt_inputs["restrictions"]}
</athlete_information>

Guidelines:
1. Include the accurate daily calorie amount for the athlete's stats and goal
2. Show protein, fat, and carbohydrate amounts per meal and for the day
3. Specify the time at which each meal should be eaten
4. Use only foods that fit the stated dietary restrictions
5. List all portion sizes in grams
6. Keep meals budget-friendly if budget is mentioned

Now there's a labelled region that Claude can reference. If the grader's reasoning occasionally complains that the model "didn't seem to use the goal field," the tags tighten that up — the model can see exactly which data came in as a unit and apply all of it consistently.

When XML tags pay off most

The gains from XML tags scale with prompt complexity. On a 10-line prompt, the lift is small. On a 300-line prompt with embedded examples, retrieved documents, tool schemas, and structured user input, the lift is substantial.

Use tags when:

• You're interpolating large amounts of data (retrieved context, long user inputs, embedded documents)
• You're mixing different types of content (code + docs, examples + instructions, multiple data sources)
• You want the prompt structure to be self-documenting — useful for you, too, not just the model
• You're interpolating multiple named variables that each have their own meaning

Even short prompts benefit from tags as soon as they include any embedded content, because the tags make the authorial intent obvious: you, the prompt writer, can tell at a glance what role each block is playing.

The real benefit is robustness

On the meal plan eval, adding tags will nudge the score a little but not dramatically. The real value of XML tags is robustness under scale — as your prompt grows and gets reused across many inputs, the tagged structure prevents the slow drift of weird failures caused by Claude misinterpreting which text belongs to which section. You won't always see the benefit in a pristine controlled eval; you will definitely see it when production traffic starts hitting edge cases.

Reach for XML tags whenever your prompt has more than one kind of content in it. Make the tag names descriptive. And don't worry about whether the XML is "well-formed" — Claude isn't parsing it as XML, it's treating it as strong structural hints, and the hints work regardless of whether your closing tags are strictly valid.