XML Structuring and Few-Shot Prompting

Using XML-like tags to separate prompt components and using worked examples to pin down exact output format.

Prompt Engineering·Lesson 2 of 6·8 min

Two closely related but distinct techniques show up constantly on the exam: wrapping prompt components in XML-like tags, and giving the model worked examples (few-shot prompting). They solve different problems and are often used together.

XML structuring

When a prompt mixes several kinds of content — instructions, background context, reference documents, examples, the actual question — the model has to infer where one section ends and another begins. Wrapping each component in tags such as <instructions>, <context>, <document>, or <examples> removes that ambiguity. The tags do not need to follow a formal schema; they just need to be consistent and used with a closing tag that matches the opening tag.

This matters most for long prompts, not short ones. A two-sentence prompt with one instruction does not benefit from tagging. A prompt that includes a 2,000-word reference document, a set of formatting rules, and three examples benefits a lot, because without tags the model may conflate the example text with the actual task input, or treat part of the reference document as an instruction.

Few-shot prompting

Few-shot prompting means including 2-5 worked input/output pairs that demonstrate the exact pattern you want, rather than describing that pattern in prose. It is the right tool when the desired output has a precise shape that is hard to specify in words: a particular JSON key ordering, a specific tone and length, a formatting convention like how to cite sources or how to abbreviate units. Instructions alone tend to under-specify these details; examples remove the ambiguity directly.

Few-shot and XML structuring combine naturally: wrap each example pair in its own <example> tags, with nested <input> and <output> tags, so the model can clearly tell where one example ends and the next begins, and can distinguish the examples block from the real task at the end of the prompt.

Exam trap A question presents a failing extraction prompt that already has clear, well-written prose instructions describing the desired JSON format, but the model keeps producing slightly wrong field names or ordering. The tempting wrong answer is "add more detailed instructions explaining the format." The correct answer is to add 2-3 few-shot examples instead — the problem is that the desired pattern is precise and hard to fully specify in prose, which is exactly the case few-shot solves better than more instructions.

A prompt asks Claude to convert freeform customer complaints into a structured triage note with fields for severity, category, and a one-line summary written in a specific terse style ("Customer unable to log in after password reset; sev 2"). Prose instructions describing "terse, sev-N style" produce inconsistent phrasing across calls. Adding three examples of complaint-to-triage-note pairs, each wrapped in <example> tags, fixes the inconsistency because the exact phrasing convention is something the model can copy from examples far more reliably than it can infer from a description of "terse style."

Choosing tag names and nesting

There is no reserved or required tag vocabulary — <context>, <background>, and <reference_material> are all equally valid choices, as long as you are consistent within a prompt and the opening and closing tags match. What matters is that each distinct kind of content gets its own tag, and that the actual task or question is clearly set apart from the supporting material, typically placed last and wrapped in something like <task> so the model knows where instructions end and the live request begins. Nesting is fine and often useful: a <examples> block containing several <example> children, each with its own <input> and <output>, is a common and reliable structure.

How many examples, and how to choose them

Two to five examples is the typical range. Fewer than two does not really establish a pattern; beyond five, returns diminish quickly and you are mostly spending tokens. Example selection matters more than example count: examples should cover the edge cases you actually care about, not just the easy, typical case repeated with different wording. If the real task includes some inputs that are ambiguous or unusual, include at least one example that shows the desired behavior on that kind of input, since the model will generalize from whatever pattern the examples actually demonstrate — including edge-case handling if you show it, or ignoring edge cases if you don't.

When XML tagging is unnecessary overhead

For a short, single-purpose prompt with one instruction and one piece of input text, adding tags is not wrong but adds no measurable benefit, and the exam sometimes uses this to test whether you over-apply techniques. The signal to reach for tagging is prompt complexity — multiple distinct content types coexisting in one prompt — not prompt length alone.

Try it

Pick a task where you currently only describe the output format in prose (for example, extracting structured fields from freeform text). Send it once with prose instructions only, then again with the same instructions plus 3 few-shot examples wrapped in <example> tags, including at least one edge-case example. Run each version against 5 different inputs, including one deliberately tricky one, and count how often the output format deviates in each case.