Missing Closing Tag Repair Prompt for XML

This prompt is designed for backend platform engineers and integration developers who operate XML processing pipelines where a large language model generates structured XML documents that are occasionally truncated by token limits, streaming interruptions, or model early-stopping. The primary job-to-be-done is to recover a well-formed, schema-valid XML document from a partial, malformed input that is missing one or more closing tags. The prompt instructs the model to infer the correct closing tags, repair any broken attribute quoting, and restore proper tag nesting without altering the existing content or inventing new element bodies. This is a post-generation repair step, not a content generation or schema design task.

Use this prompt when you have a partial XML string that fails a standard XML parser with errors such as 'unexpected end of file', 'missing closing tag', or 'unclosed token'. The input must contain enough structural context for the model to determine the intended hierarchy—typically a truncated document where the opening tags and most of the content are intact, but the final closing tags are absent. The prompt is most effective when paired with a known XML Schema Definition (XSD) or a set of expected parent-child relationships that can be provided as [CONSTRAINTS]. Do not use this prompt for XML documents that are entirely garbled, have no discernible tag structure, or require content generation to fill missing element values. It is also inappropriate for documents where the truncation point occurs inside a critical data field whose value cannot be inferred without external knowledge.

Before routing to this prompt, your application harness should first attempt standard XML repair heuristics: closing unclosed tags in reverse order of opening, fixing obvious quote mismatches, and stripping trailing incomplete content. If those deterministic methods fail, this prompt becomes the recovery path. The prompt expects you to supply the partial XML as [INPUT], an optional [XML_SCHEMA] or tag-nesting rules as [CONSTRAINTS], and a clear [OUTPUT_SCHEMA] specifying that only well-formed XML should be returned with no explanatory text. For high-stakes pipelines—such as configuration generation, financial reporting, or clinical document processing—always route the repaired output through XML schema validation and a human review step before the document reaches downstream systems. The next section provides the exact prompt template you can copy and adapt.

This prompt template is designed to be copied directly into your application code or prompt management system. It instructs the model to act as an XML repair engine, taking a truncated XML string and returning only the repaired, well-formed document. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can wire it into a production harness without manual string surgery.

textCopy
You are an XML repair engine. Your only job is to repair truncated XML documents.

You will receive an XML document that was cut off mid-generation. The document may be missing closing tags, have unclosed attribute values, or contain incomplete nested structures.

Your task:
1. Analyze the provided XML fragment to understand its structure, namespace declarations, and tag hierarchy.
2. Infer and insert all missing closing tags to make the document well-formed.
3. Repair any unclosed attribute values by adding the missing quotation mark.
4. Preserve all existing content, attributes, and structure exactly as provided. Do not change, add, or remove any content except the minimum required to close open elements.
5. Do not add any commentary, explanation, or markdown formatting. Output only the repaired XML document.

Input XML:
[TRUNCATED_XML]

Repaired XML:

To adapt this template, replace [TRUNCATED_XML] with the partial XML string from your application. For stricter control, you can add an [XML_SCHEMA] placeholder to provide an XSD or DTD for validation-aware repair. If the document uses a known root element, prepend a constraint like The root element must be <[ROOT_ELEMENT]>. Always test the repaired output with a strict XML parser before returning it to any downstream system. For high-risk pipelines, route outputs that fail parser validation to a human review queue rather than silently accepting malformed XML.

This prompt is designed to be called as a post-generation repair step, not as the primary generation prompt. Wire it into your application immediately after an XML validation failure. The typical flow is: (1) receive raw model output, (2) attempt XML parsing, (3) on parse failure, extract the partial XML string and the parser error message, (4) call this repair prompt with both the partial XML and the error context, (5) attempt to parse the repaired output, and (6) either proceed with the valid XML or escalate to a human or dead-letter queue after a defined retry budget is exhausted.

Input assembly: The prompt expects two variables: [PARTIAL_XML] (the truncated or malformed XML string) and [ERROR_CONTEXT] (the parser error message, line number, and column if available). Do not pass the entire conversation history or unrelated context—this prompt works best with a narrow, focused input. If your XML has a known schema, include a [SCHEMA_HINT] variable with the expected root element and required child elements to guide the repair. Model choice: Use a model with strong code and structure reasoning (GPT-4o, Claude 3.5 Sonnet, or equivalent). Smaller or older models often introduce new structural errors during repair. Set temperature=0 to maximize deterministic, well-formed output. Validation gate: After receiving the repaired XML, run it through your standard XML parser. If parsing fails again, increment a retry counter. On the second retry, include the new error message in [ERROR_CONTEXT] to give the model more specific guidance. Do not retry more than twice without human review—beyond two attempts, the model is likely to hallucinate content rather than repair structure.

Logging and observability: Log every repair attempt with: the original partial XML length, the parser error, the repaired XML length, parse success/failure, and the retry count. This data is critical for detecting systemic issues—if repair rates drop below 90%, your primary generation prompt likely needs adjustment, not more repair attempts. Tool integration: If your application uses function calling, expose this prompt as a tool with a schema like repair_xml(partial_xml: string, error_context: string, schema_hint?: string) -> repaired_xml: string. This allows an agent or orchestrator to call repair automatically when an XML validation tool returns an error. When to avoid this prompt: Do not use this prompt for XML documents that are missing more than 30% of their expected content—at that point, regeneration with the original task context is more reliable than repair. Do not use it for security-critical XML (e.g., SAML assertions, signed documents) where structural repair could alter security semantics. In regulated environments, flag all repaired XML for human review before it enters downstream systems of record.