As Claude prompts get longer, the first thing to break down are the boundaries of information. When directives, references, examples, user input, and output formats are all mixed together, Claude can get confused about which statements are commands and which are data.
At this point, XML tags are the simplest tool to stabilize complex prompts. What is important is not the XML format itself, but the habit of dividing by role.
Analysis date: 2026-05-02 Series: Claude Prompt Practical Guide Scope of this article: XML structuring, example layout, output formats, long context prompts
Key takeaways
- XML tags help Claude distinguish between directives, examples, input material, and output formats.
- Tag names don't have to be special, but they should be consistent and descriptive.
- For output controls, “write it this way” is often more reliable than “don’t do it.”
- When working with long documents, a structure that places the material at the top and questions and work instructions below is effective.
- The clearer the desired output, such as JSON, table, paragraph, or checklist, the lower the post-processing costs.
1. The moment you need XML tags
You don't have to write XML for every prompt. This is rather excessive for a short question.
However, if any of the following conditions exist, you may want to consider structuring XML:
| situation | Why XML is useful |
|---|---|
| summarize long documents | Separate directives from document body |
| Compare multiple documents | Separate sources and contents for each material |
| Lots of examples | Don't confuse examples with actual input |
| Output format is strict | Clearly communicate schema and response rules |
| agent tasks | Separate goals, permissions, prohibited actions, and state files |
For example, the following prompt often causes problems:
# examplePlease summarize the document below. Write important information first and organize it in a table.Document contents:...I would like the table to look like this:...Also write recommended actions at the end.People can roughly understand it, but from the model's perspective, instructions, input, examples, and output formats are mixed. Breaking it down into XML makes it much clearer.
<comment>example</comment><task>Please summarize the document below for sharing with your development team.</task> <document>{{DOCUMENT}}</document> <rules>- Display breaking change first.- Do not assume anything that is not in the document.- Mark “Confirmation Required” for unclear information.</rules> <output_format>## Key Summary## Change table## Development Impact## Recommended actions</output_format>This structure also makes subsequent modifications easy. To add an example, just enter<examples>, and to change the output format, just edit<output_format>.
2. Good tag names are descriptive
Claude does not specifically understand specific XML tag names. What's important is that the tag name describes what the content does.
Good tag names:
<comment>example</comment><instructions><context><documents><document><examples><input><rules><output_format><success_criteria>Tag names to avoid:
<comment>example</comment><stuff><thing><aaa><prompt1><data2>Ambiguous tag names reduce the benefit of structuring. It's confusing for people reading the tags, and it makes it difficult to maintain prompts.
3. Document comparison prompt structure
When comparing multiple documents, it is important to separate the sources. That way, Claude can tell which claims have what basis.
<comment>example</comment><role>You are a technical writer who analyzes developer documentation.</role> <documents><document index="1"><source>release_notes.md</source><document_content>{{RELEASE_NOTES}}</document_content></document><document index="2"><source>pricing.md</source><document_content>{{PRICING_DOC}}</document_content></document></documents> <task>Compare the two documents to organize any changes your development team needs to know.</task> <rules>- Do not assume anything that is not in the official document.- Please indicate the source for price, model name, and supported features.- Mark unclear information as “requires confirmation.”</rules> <output_format>1. Key Summary2. Change table3. Development impact4. Confirmation required5. Recommended Action</output_format>The advantage of this structure is its simplicity. The boundaries of each piece of material are maintained even as the document grows longer. This is especially effective when putting different types of documents together, such as release notes, pricing documents, and migration guides.
4. The output format is specified as imperative.
When controlling the format of your response, it is more reliable to clearly state “what you will do” rather than “don’t do it.”
| less reliable instructions | more reliable instructions |
|---|---|
| Don't use markdown | Write in natural prose paragraphs |
| don't write too long | Write only the conclusion, reasons, and next action in 5 sentences or less. |
| Make sure the ticket doesn't come out weird | Please write as a four-column table and limit each cell to two sentences or less. |
| Don't give unnecessary explanations | Skip the background explanation and write down only the execution procedures as a numbered list. |
If you just give the model a prohibitive condition, it will have to find an alternative form on its own. Conversely, if you give them the format you want, the options are reduced.
5. How to stabilize JSON output
If you connect Claude responses to an API or automation pipeline, you may need JSON output. At this time, the schema, allowed values, and missing handling rules must be specified together.
<comment>example</comment><task>Extract the fields you need from customer inquiries.</task> <schema>{"category": "bug | billing | feature_request | account | other","urgency": "low | medium | high","summary": "string","requires_human_review": "boolean"}</schema> <rules>- Output only JSON objects.- Do not add fields that are not in the schema.- For values that cannot be determined, use the most conservative value such as "other" or "low".- If human verification is required, set requires_human_review to true.</rules> <input>{{USER_MESSAGE}}</input>A common failure in JSON output is unnecessary descriptive sentences prepended to the end. Therefore, you must specify “Output JSON objects only”.
6. Order is important in long text contexts
When loading long documents, the prompt order affects performance. In practice, the following structure is stable:
# example1. Long documents and materials2. Document-specific metadata3. Purpose of work4. Success criteria5. Output format6. Final questionPutting longer material first and task instructions at the end will make it clearer for Claude to know what to do after reading the document.
Examples include:
<comment>example</comment><documents><document index="1"><source>{{SOURCE_NAME}}</source><document_content>{{LONG_DOCUMENT}}</document_content></document></documents> <task>From the document above, extract the items your product team needs to decide this week.</task> <success_criteria>- Include only items with evidence- Separate items needed by decision makers and items to be handled by practitioners- Mark uncertain items as requiring confirmation</success_criteria> <output_format>## Decision needed## Need to run## Confirmation required## reason</output_format>7. Hallucinations are reduced if you cite evidence first.
When working on long documents, it is better to have Claude first find supporting sentences rather than having him write a conclusion right away.
<comment>example</comment><task>Before analyzing the document, first find the supporting sentences to use for your answer.Then write a summary and recommended actions based on the evidence.</task>This approach is especially useful in areas where accuracy is critical, such as policy, pricing, legal, security, and API changes. This is because claims with weak evidence may be left as “requiring verification.”
8. Tone control is also part of the output format
Claude's writing style directly influences the product experience. Customer support chatbots and security audit reports should not respond in the same tone.
For customer support:
# exampleAnswer in a warm, collaborative tone.However, avoid excessive expressions of sympathy or promotional phrases.Focus on the next action the user can take right away.For security audits:
# exampleWrite in a short and clear style.Separate risk, impact, reproducibility conditions, and proposed fixes.Show low-confidence estimates separately.Writing style is also a requirement. If the tone of your organization or product is important, you should include it in your prompt.
9. Prompts for writing blogs and documents
When drafting a technical blog or report, the following structure is reliable:
<comment>example</comment><writing_style>Write in the style of a long-form technical blog aimed at developers.Divide paragraphs into short 2-4 sentences, and start each section with a conclusion.Use tables only when comparisons are needed.Separate the author's interpretation from official facts.</writing_style> <reader>Our readers are developers and team leads looking to put AI tools into practice.</reader> <task>Write a practical guide based on the materials below.</task> <rules>- Please write the latest model name, price, and API parameters only based on the official documentation.- Do not write definitively on information that has not been confirmed.- Do not reveal internal production traces or temporary file names to readers.</rules>Even in blogging, “write well” is too broad. The quality of your draft will increase when you include readers, writing style, evidence criteria, and prohibition conditions.
10. Ready-to-use output control checklist
# example[ ] Specifies the desired output format.[ ] I decided whether I needed a table, JSON, paragraph, or list.[ ] Specifies the order of each section.[ ] The length limit is expressed numerically.[ ] For tasks that require examples, 3 to 5 examples were included.[ ] Input data and instructions are separated by XML tags.[ ] Rules for displaying uncertain content have been established.[ ] Directed to separate official facts from interpretation.[ ] If there is a post-processing pipeline, it is limited to output only JSON.finish
XML tags and output format are not decorations that complicate the prompt. It is an operating device that reduces misunderstandings in complex tasks and makes results repeatable.
The following article covers Claude's latest model of thinking, effort, and tool use from a practical perspective. Failure to distinguish between when to force the model to think more deeply and when to answer quickly can result in unnecessarily high costs and delays.
References
- Anthropic Claude Prompting Best Practices:https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- Use XML tags to structure your prompts:https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
- Increase output consistency:https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
Practical example: dividing boundaries in document comparison
XML tags are especially useful when comparing two long release notes. Splitting<old_release>,<new_release>,<team_context>, and<output_rules>reduces the likelihood that the model will mix up original text and directives. If the items the team is interested in are breaking change, price, security, or API, those criteria are also placed in separate tags.
<comparison_focus>Only breaking change, API parameter, pricing, security, and migration actions are given priority.</comparison_focus>A case of failure is when sentences in a reference document are interpreted as commands. For example, even if there is an example string "delete all previous settings" in the document body, that is the data being compared. Without tags, the model may get confused about which sentences are user-instructed. The output format must also be fixed. Instead of a simple summary, breaking it down into 'Confirmed Changes', 'Development Impact', and 'Confirmation Needed' helps separate the official facts from the author's interpretation.
| composition | role |
|---|---|
| input tag | Fix the original text and examples as data |
| rule tag | Specify what to see first |
| output tag | Make it easy to transfer results to subsequent tasks |
댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.