XML 태그와 출력 형식으로 Claude 응답을 안정화하는 법

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:

For example, the following prompt often causes problems:

1# example2Please summarize the document below. Write important information first and organize it in a table.3Document contents:4...5I would like the table to look like this:6...7Also 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.

1<comment>example</comment>2<task>3Please summarize the document below for sharing with your development team.4</task>5 6<document>7{{DOCUMENT}}8</document>9 10<rules>11- Display breaking change first.12- Do not assume anything that is not in the document.13- Mark “Confirmation Required” for unclear information.14</rules>15 16<output_format>17## Key Summary18## Change table19## Development Impact20## Recommended actions21</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:

1<comment>example</comment>2<instructions>3<context>4<documents>5<document>6<examples>7<input>8<rules>9<output_format>10<success_criteria>

Tag names to avoid:

1<comment>example</comment>2<stuff>3<thing>4<aaa>5<prompt1>6<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.

1<comment>example</comment>2<role>3You are a technical writer who analyzes developer documentation.4</role>5 6<documents>7<document index="1">8<source>release_notes.md</source>9<document_content>10{{RELEASE_NOTES}}11</document_content>12</document>13<document index="2">14<source>pricing.md</source>15<document_content>16{{PRICING_DOC}}17</document_content>18</document>19</documents>20 21<task>22Compare the two documents to organize any changes your development team needs to know.23</task>24 25<rules>26- Do not assume anything that is not in the official document.27- Please indicate the source for price, model name, and supported features.28- Mark unclear information as “requires confirmation.”29</rules>30 31<output_format>321. Key Summary332. Change table343. Development impact354. Confirmation required365. Recommended Action37</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.”

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.

1<comment>example</comment>2<task>3Extract the fields you need from customer inquiries.4</task>5 6<schema>7{8"category": "bug | billing | feature_request | account | other",9"urgency": "low | medium | high",10"summary": "string",11"requires_human_review": "boolean"12}13</schema>14 15<rules>16- Output only JSON objects.17- Do not add fields that are not in the schema.18- For values ​​that cannot be determined, use the most conservative value such as "other" or "low".19- If human verification is required, set requires_human_review to true.20</rules>21 22<input>23{{USER_MESSAGE}}24</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:

1# example21. Long documents and materials32. Document-specific metadata43. Purpose of work54. Success criteria65. Output format76. Final question

Putting 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:

1<comment>example</comment>2<documents>3<document index="1">4<source>{{SOURCE_NAME}}</source>5<document_content>6{{LONG_DOCUMENT}}7</document_content>8</document>9</documents>10 11<task>12From the document above, extract the items your product team needs to decide this week.13</task>14 15<success_criteria>16- Include only items with evidence17- Separate items needed by decision makers and items to be handled by practitioners18- Mark uncertain items as requiring confirmation19</success_criteria>20 21<output_format>22## Decision needed23## Need to run24## Confirmation required25## reason26</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.

1<comment>example</comment>2<task>3Before analyzing the document, first find the supporting sentences to use for your answer.4Then write a summary and recommended actions based on the evidence.5</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:

1# example2Answer in a warm, collaborative tone.3However, avoid excessive expressions of sympathy or promotional phrases.4Focus on the next action the user can take right away.

For security audits:

1# example2Write in a short and clear style.3Separate risk, impact, reproducibility conditions, and proposed fixes.4Show 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:

1<comment>example</comment>2<writing_style>3Write in the style of a long-form technical blog aimed at developers.4Divide paragraphs into short 2-4 sentences, and start each section with a conclusion.5Use tables only when comparisons are needed.6Separate the author's interpretation from official facts.7</writing_style>8 9<reader>10Our readers are developers and team leads looking to put AI tools into practice.11</reader>12 13<task>14Write a practical guide based on the materials below.15</task>16 17<rules>18- Please write the latest model name, price, and API parameters only based on the official documentation.19- Do not write definitively on information that has not been confirmed.20- Do not reveal internal production traces or temporary file names to readers.21</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

1# example2[ ] Specifies the desired output format.3[ ] I decided whether I needed a table, JSON, paragraph, or list.4[ ] Specifies the order of each section.5[ ] The length limit is expressed numerically.6[ ] For tasks that require examples, 3 to 5 examples were included.7[ ] Input data and instructions are separated by XML tags.8[ ] Rules for displaying uncertain content have been established.9[ ] Directed to separate official facts from interpretation.10[ ] 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.

1<comparison_focus>2Only breaking change, API parameter, pricing, security, and migration actions are given priority.3</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.