XML tags help LLMs parse prompts more accurately, leading to higher-quality outputs.
This guide covers best practices for structuring mode instructions using XML.
Clearly separate different parts of your instructions and ensure well-structured content
Reduce errors caused by the model misinterpreting parts of your instructions
Easily find, add, remove, or modify parts of instructions without rewriting everything
Having the model use XML tags in its output makes it easier to extract specific parts of responses
Use the same tag names throughout your instructions
Always use for workflow steps, not sometimes or
Tag names should clearly describe their content
detailed_steps
error_handling
validation_rules
stuff
misc
data1
Nest tags to show relationships and structure
Gather requirements
Validate inputs
Process data
Generate output
For step-by-step processes
High-level description
Required condition 1
Required condition 2
Step Title
What this step accomplishes
Specific action to take
How to verify success
For providing code examples and demonstrations
What this example demonstrates
When to use this approach
// Your code example here
Key points about the implementation
For rules and best practices
The specific rule or guideline
Why this is important
When this doesn't apply
For documenting decision criteria and guardrails
Do not include runtime implementation details (no function names, command names, UI entry points, or execution syntax)
Prefer the smallest change that satisfies the request
Prefer a single source of truth; avoid duplicated rules across files
Ask a clarifying question only when critical ambiguity remains
Constraints and guardrails (e.g., permissions, file restrictions, or other limits).
What to verify after changes (cohesion, examples updated, boundaries clear).
Use consistent indentation (2 or 4 spaces) for nested elements
Add line breaks between major sections for readability
Use XML comments to explain complex sections
Use CDATA for code blocks or content with special characters:
your code here
Use attributes for metadata, elements for content:
The actual step content
Keep narrative outputs concise; reserve detailed exposition for code, diffs, and structured outputs. Prefer readable, maintainable code with clear names; avoid one-liners unless explicitly requested.
Avoid completely flat structures without hierarchy
Do this
Then this
Finally this
Do this
Then this
Finally this
Don't mix naming conventions
Mixing camelCase, snake_case, and kebab-case in tag names
Pick one convention (preferably snake_case for XML) and stick to it
Avoid tags that don't convey meaning
data, info, stuff, thing, item
user_input, validation_result, error_message, configuration
Avoid asking the user to confirm obvious next steps on straightforward tasks
Asking multiple clarifying questions before acting when the task is simple
Proceed when next steps are clear; ask only when critical ambiguity remains; document assumptions
Avoid repetitive or redundant searches when the relevant target is already identified
Running multiple identical searches instead of acting
Stop once the change is clearly identified; then implement
Avoid duplicating runtime behavior that is already defined elsewhere
Documenting execution constraints, operation ordering, or invocation details
Focus on intent, artifacts, decision criteria, and validation expectations
Reference XML content in instructions:
"Using the workflow defined in <workflow> tags..."
Combine XML structure with other techniques like multishot prompting
Use XML tags in expected outputs to make parsing easier
Create reusable XML templates for common patterns