Claude Code XML Tags: Structuring Clear Instructions

XML tags in Claude Code are a way to label sections of a prompt so that Claude can distinguish instructions from context, examples from the actual task, and reference files from the request. They do not change what Claude is allowed to do, but they do make it easier for Claude to understand what each part of a long prompt means. A tool like fenbs keeps reusable prompt patterns and project rules in one place so you can load them into any session without rewriting them each time.

You do not need XML tags for every prompt. They help most when a prompt contains several distinct parts that could otherwise be confused.

What XML tags do in a prompt

XML tags are paired labels that wrap a section of text. Claude reads them as markers that describe the role of the content inside. A tag named <instructions> signals that the enclosed text should be treated as directions rather than input material. A tag named <context> signals that the enclosed text is background information.

Claude understands these labels from its training. You do not need to define what each tag means before using it. Short, descriptive names work best. Tags like <task>, <context>, <example>, <code>, and <reference> communicate their purpose clearly without further explanation.

XML tags are most useful when a prompt is long and would otherwise require Claude to infer which part is the instruction and which is the material to work on. In a short prompt, they add no benefit.

Common patterns that benefit from XML tags

The clearest use case is separating the task from the material. If you are asking Claude to review a document, you can wrap the document in <document> tags and the instructions in <instructions> tags. Claude can then process the document without accidentally treating part of it as a direction.

<instructions>
Review the following spec for missing edge cases.
List each gap as a numbered point.
</instructions>

<spec>
[your specification text here]
</spec>

Another common pattern is providing examples. Wrapping each example in an <example> tag makes it clear to Claude that the enclosed text is a model to follow, not the actual input to process.

<example>
Input: short paragraph
Output: three-word summary
</example>

<input>
[your actual paragraph here]
</input>

CLAUDE.md versus XML tags

CLAUDE.md (or AGENTS.md) is the right place for standing instructions that apply to every session in a repository. Rules about style, what files to edit, what tools to use, and what to avoid belong there. Claude Code reads the file automatically at the start of a session, so you do not include it in each prompt.

XML tags belong in the prompt itself, wrapping content that is specific to that request. Use CLAUDE.md for the persistent rules and XML tags to organize the material you hand Claude for a particular task.

If you find yourself pasting the same XML-wrapped reference material into many sessions, consider whether it belongs in CLAUDE.md or in a project file that Claude reads by reference. The goal is to write the important facts once.

What XML tags cannot do

XML tags do not enforce permissions or restrict Claude's behavior. A <restricted> tag does not prevent Claude from reading or acting on the content inside it. Tags clarify structure for Claude; they do not set boundaries around what Claude may do.

Permission and access control is handled by the tool or platform you are working in, not by prompt structure. In Claude Code, what Claude can do is set by the tool's permissions and by your CLAUDE.md instructions. For shared project rules across a team, the guide to Claude Code worktrees covers how to keep project settings consistent across parallel sessions.

Tips for using XML tags well

Use short, descriptive tag names. Long or unusual names add reading overhead without improving Claude's understanding. Stick to names that describe the content plainly: <task>, <constraints>, <files>, <background>.

Be consistent. If you use <reference> in one prompt and <context> in another for the same kind of material, you add variability without benefit. Settling on a small set of tag names for your common use cases makes your prompts easier to reuse and review.

Do not wrap everything. A one-sentence instruction does not need XML wrapping. Reserve tags for prompts where the structure genuinely helps. Start without them and add them when a longer prompt produces confusing results.

When not to use XML tags

XML tags are not the right tool for every prompt. A one-sentence instruction does not benefit from wrapping. Using tags for simple requests adds reading overhead without improving Claude's understanding. Start without them and add tags when a longer prompt produces confusing results.

Resist the urge to create a deep tag hierarchy. Nesting <task> inside <context> inside <session> rarely helps. Claude does not need elaborate structure to understand a well-written prompt. Two or three top-level tags that label the major sections are usually sufficient.

How to do this with fenbs

1. Create a free account and set up a project for your Claude Code work.
2. Open Skills and prompts and save the XML-structured prompt patterns that work well for you, for example your standard spec-review format or your example-wrapping template.
3. Connect Claude Code from Integrations. Claude Code connects over MCP with a browser sign-in.
4. At the start of a Claude Code session, ask it to list your saved prompts and read the ones relevant to the task. It can follow a saved template without you pasting it each time.
5. If a prompt pattern becomes a team standard, add it to Decisions and rules with a short note on why you settled on that structure.