XML Prompt Templates and Patterns

The XML output template

Most operators who try XML prompting write the schema last, as an afterthought. That is backwards. The schema is the prompt. The task description exists to serve it. Here is a complete annotated template you can copy directly -- comments explain each component, then strip them before submitting.

<!-- SECTION 1: Role assignment -->
<!-- Specific operational identity. Not "you are a helpful assistant" -- a named function. -->
You are a senior operations analyst. You produce structured XML output from unstructured
source material. You do not summarize or interpret -- you populate fields as defined.

<!-- SECTION 2: Task statement -->
<!-- One sentence. What to do, what to do it with, what to return. -->
Review the project notes below and return a structured XML document matching the schema.

<!-- SECTION 3: Output rules as a bullet list -->
<!-- This block sets hard constraints before the model sees the schema. -->
Rules:
- Return valid, well-formed XML only. No prose before or after the XML block.
- Every tag in the schema must appear in the output. Use empty tags for missing data.
- Wrap any multi-line text content in CDATA sections to prevent parsing errors.
- Use consistent tag naming: lowercase, hyphenated (e.g. <file-path>, not <FilePath>).
- Do not add tags that are not in the schema.

<!-- SECTION 4: XML schema with semantic tags -->
<!-- Tag names describe their contents. A reader should understand the structure at a glance. -->
Return this exact structure:

<project-update>
  <client-name></client-name>
  <report-date></report-date>
  <status></status>  <!-- On Track | At Risk | Blocked | Complete -->
  <summary><![CDATA[
    Multi-sentence summary goes here. CDATA prevents special characters from breaking the parser.
  ]]></summary>
  <deliverables>
    <deliverable>
      <title></title>
      <owner></owner>
      <deadline></deadline>
      <status></status>
    </deliverable>
  </deliverables>
  <blockers>
    <blocker><![CDATA[Description of the blocker]]></blocker>
  </blockers>
</project-update>

<!-- SECTION 5: Array pattern for multiple records -->
<!-- When processing more than one client or document, wrap in a root container element. -->
If processing multiple records, wrap all elements in a root container:
<updates>
  <project-update>...</project-update>
  <project-update>...</project-update>
</updates>

[PASTE YOUR SOURCE MATERIAL HERE]

Strip the comment blocks before you submit. What remains is a complete instruction set: role, task, rules, schema, and array wrapper. The rules bullet list is load-bearing -- it goes before the schema, not after, so the model reads constraints before it starts generating.

---

Three XML patterns for structured output

These three templates cover recurring documentation tasks across client engagements. Each is ready to deploy. Replace the bracketed placeholders with your actual source material.

Pattern 1: Portfolio status tracker

Track deliverables across multiple client engagements in a single structured document. Paste your weekly notes from all active clients and get back a structured record you can pass directly into the next prompt or automation without re-describing any context.

You are a senior operations analyst. You extract structured status data from
fractional operator notes and return valid XML only. No prose. No code fences.
Begin with <portfolio> and end with </portfolio>.

Rules:
- Every <engagement> must include all attributes shown.
- Every <deliverable> must include all child elements shown.
- Use CDATA for any field containing notes, descriptions, or free text.
- Use empty tags rather than omitting fields.

Return this structure:

<portfolio>
  <engagement id="[client-slug]" name="[Client Name]" status="[On Track | At Risk | Blocked | Complete]">
    <deliverable>
      <title></title>
      <owner></owner>
      <deadline></deadline>
      <status></status>  <!-- Not Started | In Progress | Complete | Overdue -->
      <notes><![CDATA[Any relevant notes here]]></notes>
    </deliverable>
  </engagement>
</portfolio>

[PASTE WEEKLY STATUS NOTES HERE -- ALL CLIENTS]

The id attribute on each is what makes this useful downstream. When you pass this document to the next prompt in a chain, you can reference a specific engagement by its slug without re-describing the whole portfolio.

Pattern 2: Content change log

Track document revisions across a client engagement. Without a structured change log, version disputes with clients have no paper trail. This pattern captures what changed, which section it touched, and why -- for policy documents, deliverables, or any output that goes through multiple rounds of review.

You are a documentation analyst. You extract revision records from change notes
and return valid XML only. No prose. Begin with <changes> and end with </changes>.

Rules:
- Each <revision> must have an operation attribute: ADD, EDIT, or REMOVE.
- Wrap all before/after text in CDATA sections.
- Use empty <before> tags for ADD operations. Use empty <after> tags for REMOVE operations.
- Do not combine multiple changes into one <revision> element.

Return this structure:

<changes>
  <document name="[Document Title]" version="[v1.0, v1.1, etc.]">
    <revision operation="[ADD | EDIT | REMOVE]">
      <section></section>
      <before><![CDATA[Original text or empty for new additions]]></before>
      <after><![CDATA[Revised text or empty for removals]]></after>
      <reason><![CDATA[Why this change was made]]></reason>
    </revision>
  </document>
</changes>

[PASTE REVISION NOTES OR REDLINED DOCUMENT CONTENT HERE]

Pattern 3: Process documentation (SOP)

Convert rough process notes into a structured SOP that names every input, output, owner, and dependency. This feeds directly into onboarding docs or client-facing operating guides.

You are a process documentation specialist. You convert unstructured process notes
into structured XML SOPs. Return valid XML only. Begin with <process> and end with </process>.

Rules:
- Steps must appear in execution order.
- Each <step> that depends on a prior step must include a <depends-on> tag.
- Wrap all descriptive content in CDATA.
- Use empty tags for fields not present in the source material.

Return this structure:

<process>
  <name></name>
  <owner></owner>
  <frequency></frequency>  <!-- Daily | Weekly | Per-engagement | Ad hoc -->
  <step id="[1, 2, 3...]">
    <title></title>
    <depends-on></depends-on>  <!-- step id this requires, or empty -->
    <owner></owner>
    <input><![CDATA[What this step needs to start]]></input>
    <output><![CDATA[What this step produces when complete]]></output>
    <instructions><![CDATA[Step-by-step instructions]]></instructions>
  </step>
</process>

[PASTE PROCESS NOTES HERE]

---

Common XML mistakes

XML is less forgiving than JSON. A single structural error breaks the entire document. These four mistakes account for the majority of failed outputs.

Unclosed tags. Every opening tag needs a closing tag. On Track with no invalidates every element that follows it. The fix is to name the requirement explicitly in your rules: "Every opening tag must have a matching closing tag." Models follow explicit structural rules reliably when stated before the schema.

Missing CDATA around free text. Any field containing natural language -- summaries, notes, instructions, descriptions -- should be wrapped in . Without it, characters like &, <, >, and " inside the content break the parser. You won't always get an error message. The document will silently fail to parse. Use CDATA for every text field as a default, not as an exception.

Inconsistent tag naming. A schema that mixes , , and across different records is technically invalid and breaks any automated downstream process. Set a naming convention in the rules section and enforce it with one line: "Use lowercase hyphenated tag names throughout." This is one of the clearest advantages of the rules-before-schema structure -- constraints are read before the model generates a single tag.

Deeply nested structures. More than three levels of nesting ( > > > ) increases the chance the model loses track of the structure and drops a closing tag. If your schema requires deep nesting, flatten it. Move attributes to the parent element rather than adding another child level. Flatter schemas produce cleaner output and parse faster.

---

Parsing XML output

Once you have clean XML, the practical question is what to do with it.

Copy it directly into tools that accept XML. Many project management tools, CRMs, and reporting platforms have XML import functions. A portfolio status document in the pattern above pastes directly into tools that accept structured data -- no transformation required.

Feed it into the next prompt. This is the most useful pattern for fractionals managing multiple workflows. XML output from one prompt becomes the structured input for the next. You can reference specific elements by tag ("Review the elements with status Overdue") without re-describing the full context. The model reads the structure and operates on exactly the elements you specify.

Pass it to a parser for automation. Standard XML parsers exist in every major language and in no-code tools like Make and Zapier. The schemas in this guide are simple enough that a basic XPath query extracts any field. If you're building an automation, the id attributes on container elements -- like the engagement slug in Pattern 1 -- give you direct references without scanning the full document.

Use it as a durable record. XML is plain text. It versions cleanly in Git, stores in any document system, and opens in any text editor. For fractionals who need an audit trail across client engagements, an XML-based change log or SOP archive is easier to maintain than a folder of unstructured notes.

The dual-output pattern from the previous guide applies here too. Ask for a plain-text analysis first, then the XML block. Use the analysis to verify the model understood the task correctly before you pass the structured output anywhere. Two minutes of review prevents a corrupted record from entering your workflow.

> Tip: Validate your XML before you use it. Paste the output into an online XML validator (xmlvalidation.com or similar) to confirm it's well-formed. This takes ten seconds and catches the class of errors that only surface when a downstream tool rejects the document.