Claude prompting techniques: XML tags, examples, and prefill

A well-written prompt isn't about picking the magic words — it's about removing structural ambiguity. This page covers the documented techniques that fix the most common problems: Claude confusing data with instructions, inconsistent answers, and a lack of explicit reasoning.

Why XML tags fix more than a paragraph asking for care

When a prompt mixes instruction, data, and examples in the same plain-text block, Claude has to guess which is which — and sometimes gets it wrong, treating a piece of data, like a comment inside a code diff, as if it were an instruction aimed at it.

The documented fix isn't reinforcing with more adverbs ("pay attention", "don't confuse") — it's wrapping each type of content in its own tag, like ``, ``, and ``. That removes structural ambiguity instead of trying to compensate for it with emphasis, and it scales better as the prompt grows.

Multishot: examples teach the pattern better than a repeated instruction

For repetitive tasks — classifying, extracting, formatting — three to five well-chosen examples teach the output pattern in a way that rewriting the instruction can't. Claude generalizes from the pattern the examples show, not just from what the instruction sentence describes.

Position matters too: in long documents, the lengthy material goes at the top of the prompt and the question goes last. That's the order Anthropic's guidance measures as most reliable — reversing it, question first and document after, tends to make the answer worse, not better.

How to ask for explicit reasoning without extended thinking

Without extended thinking mode turned on, the documented way to still get step-by-step reasoning before the final answer is to ask for it explicitly in the prompt — for example, with a tag like `` before the answer. Claude doesn't think out loud by default; the format has to be requested.

To force a specific output format there's a complementary technique: prefill, which starts the assistant's response for you — for example, opening with `{` to push toward JSON. It works well on its own, but doesn't combine with extended thinking in the same request: the two techniques compete for the same space at the start of the response.

tool_choice and the limit of what a well-written prompt solves

When you need a specific tool to be called, without relying on the model "deciding" that from the description, the API's `tool_choice` parameter solves it deterministically — forcing a named tool, or at least forcing that some tool gets called, instead of leaving the decision to the prompt text alone.

It's the same principle as CLAUDE.md versus hooks, applied to prompting: well-written text raises the odds that the right behavior happens; a structured API parameter guarantees it.

When prompt wording isn't enough: structured outputs

Prefill helps start the response in the right format, but doesn't guarantee the rest of the response keeps following the schema to the end — that still depends on the prompt being well written. To guarantee the response always matches a schema exactly, there's structured outputs, which validates the structure programmatically instead of relying only on how the instruction is worded.

Even with structured outputs enabled, some responsibilities remain yours: the schema guarantees the format is correct, not that the values inside it make business sense. Validating the content is still the application's job, not the API's.