XML Malformation Correction Prompt Template for Configuration Files

This prompt is designed for platform and infrastructure engineering teams who need to repair model-generated XML configuration files that fail parser validation. The core job-to-be-done is recovering valid XML from a broken output so that an automated deployment pipeline, configuration management system, or application runtime can consume it without manual editing. The ideal user is an engineer building a CI/CD system, a configuration-as-code controller, or an internal platform service where a language model generates XML configs—such as Maven POMs, Apache server configs, Kubernetes XML manifests, or legacy enterprise application descriptors—and those configs must pass an XSD or DTD validation gate before being applied.

Use this prompt when the model output is structurally recognizable as XML but contains common syntactic errors: unclosed tags, mismatched opening and closing tags, missing or malformed attribute quotes, incorrect self-closing tag syntax, or namespace prefix inconsistencies. The prompt assumes you have already attempted to parse the output and received a specific parser error message, which becomes a critical input. Do not use this prompt for content-level errors where the XML is syntactically valid but semantically wrong—for example, a correct XML structure that references the wrong port number or an incorrect dependency version. Those failures require a different repair strategy, likely involving retrieval of the correct values from a source of truth rather than structural repair. Also avoid this prompt when the model output is so corrupted that no XML structure is discernible; in that case, regeneration with stricter output constraints or a different model is more reliable than attempting salvage.

Before reaching for this prompt, confirm that you have exhausted simpler fixes: retrying with a lower temperature, adding explicit XML formatting instructions to the generation prompt, or using a model with stronger XML output discipline. This prompt is a recovery mechanism, not a substitute for proper output engineering. When you do use it, always pair it with an XSD validation gate that rejects the repaired output if it still fails, and log the structural diff between the original broken XML and the repaired version so you can monitor whether the underlying generation prompt needs improvement. For high-risk production systems where invalid configuration could cause an outage, require human approval on any repair that modifies more than a configurable threshold of elements.

This prompt template is designed to be copied directly into your application's prompt layer. It instructs the model to act as a strict XML repair engine, taking a malformed XML string and a set of constraints, and returning a structurally valid, well-formed XML document. The square-bracket placeholders are the dynamic inputs your application must supply at runtime. Do not modify the core instruction logic; instead, populate the placeholders with the specific data for each repair job.

textCopy
You are an XML repair engine. Your only task is to fix malformed XML configuration files.

You will receive a malformed XML string and must return a structurally valid, well-formed XML document.

Follow these rules strictly:
1. Analyze the [MALFORMED_XML] for common errors: unclosed tags, mismatched closing tags, missing or unquoted attributes, incorrect self-closing tag syntax, and namespace prefix issues.
2. Repair all syntax errors to produce well-formed XML. Do not change the semantic content or element values unless they are syntactically invalid.
3. If a tag is unclosed, determine the correct closing point based on sibling elements and document structure. Do not guess content.
4. Ensure all attribute values are enclosed in double quotes.
5. If [TARGET_XSD] is provided, validate the repaired XML against this XSD schema. If the repaired XML violates the schema, make the minimal structural changes required to achieve schema validity, such as adding missing required elements or reordering elements. Flag any semantic changes in a processing instruction comment: <!-- REPAIR NOTE: [description of change] -->.
6. If the input is too damaged to repair with high confidence, output only the following XML comment and nothing else: <!-- REPAIR FAILED: [brief reason] -->.
7. Output ONLY the repaired XML document. Do not include any other text, explanation, or markdown fences.

[MALFORMED_XML]:
[INPUT_XML]

[TARGET_XSD]:
[OPTIONAL_XSD_SCHEMA]

To adapt this template, replace [INPUT_XML] with the broken XML string and [OPTIONAL_XSD_SCHEMA] with your XSD schema string. If no schema is available, pass an empty string or remove the entire [TARGET_XSD] block and the associated rule #5. The [MALFORMED_XML] and [TARGET_XSD] labels are part of the prompt structure and should not be removed. For high-risk configuration systems, always provide the [TARGET_XSD] to add a critical structural validation layer. The next step after generating a repair is to run the output through a native XML parser and, if a schema was provided, a validating XML reader in your application code. Never trust a model-repaired config without this programmatic validation gate.

This prompt is designed to sit inside a post-generation repair loop, not as a standalone chat interaction. The typical integration pattern is: (1) model generates XML configuration, (2) parser validation fails with specific error messages, (3) the failed XML and parser errors are fed into this prompt, (4) the corrected XML is re-validated, and (5) the loop either succeeds, retries, or escalates. The prompt expects two required inputs: [MALFORMED_XML] (the raw string that failed parsing) and [PARSER_ERRORS] (the exact error output from your XML parser or XSD validator). Optionally, provide [XSD_SCHEMA] if structural validation against a schema is required, and [CORRECTION_CONSTRAINTS] to enforce domain-specific rules like forbidden elements or required namespaces.

Validation gate and retry loop: After receiving the corrected XML, immediately run it through the same parser that produced the original errors. If the parser returns zero errors, the repair succeeded and the output can proceed downstream. If errors remain, compare the new error count to the original—if it decreased, retry with the updated XML and new errors (up to a configurable MAX_RETRIES, typically 3). If errors are unchanged or increased, break the loop and escalate for human review. Structural diff requirement: The prompt instructs the model to output a corrections_applied array describing each fix. Parse this array and compare it against the actual byte-level diff between input and output XML. If the model claims to have fixed an unclosed tag but the diff shows no change to that element, flag the output for review—this is a hallucination pattern we've observed in production. Model choice: This task benefits from models with strong code and structured text capabilities. GPT-4o and Claude 3.5 Sonnet perform well on XML repair. Avoid smaller or older models (GPT-3.5, Claude Haiku) for deeply nested or namespace-heavy XML—they tend to introduce new errors while fixing old ones. For air-gapped or private deployments, Llama 3.1 70B with careful temperature settings (0.1-0.2) is viable but requires more aggressive retry logic.

Logging and audit trail: Every repair attempt should be logged with: input XML hash, parser error count before repair, correction prompt version, model used, output XML hash, parser error count after repair, retry count, and whether human review was triggered. This audit trail is critical for configuration files that affect infrastructure, deployments, or security policies. When to avoid this prompt: Do not use this prompt for XML documents where semantic correctness matters more than syntactic validity—for example, legal contracts or medical records where a well-formed but semantically altered document is worse than a malformed one. In those cases, flag the malformed output for human correction immediately. Also avoid this prompt when the malformed XML is truncated due to token limits; use the Token Limit Truncation Recovery Prompt instead, as this prompt may hallucinate missing content rather than detecting truncation.