YAML Indentation Error Recovery Prompt

This prompt is for DevOps and platform engineers who receive LLM-generated YAML that fails to parse due to indentation errors, tab characters, or incorrect nesting levels. The job is to recover a valid YAML document that preserves all original key-value data and conforms to a provided schema, without losing semantic content. Use this prompt when a YAML parser rejects the model output with indentation-related errors and you need a structured repair before the payload can be consumed by deployment tools, configuration managers, or CI/CD pipelines.

The prompt expects three inputs: the malformed YAML string, the raw parser error message, and an optional YAML schema or example document that defines the expected structure. It instructs the model to normalize whitespace, replace tabs with spaces, correct indentation depth to match the schema's nesting hierarchy, and preserve all keys, values, comments, and anchors. The output must include the repaired YAML, a list of specific corrections made, and a boolean flag indicating whether the repair was lossless. Do not use this prompt for semantic errors like incorrect values or missing required keys—those require a different repair workflow such as the Missing Required Field Injection Prompt or the YAML Schema Validation Retry Prompt.

This prompt is not a substitute for schema validation or type checking. It focuses exclusively on whitespace and structural indentation. If the model output contains fundamentally malformed YAML syntax beyond indentation—such as unclosed quotes, invalid anchors, or duplicate keys—the repair may be partial. In those cases, wire this prompt into a broader Structured Output Repair Harness that can route to format-specific sub-prompts. For high-risk production pipelines, always validate the repaired YAML against the target schema and log both the original error and the repair diff before applying the configuration.

This template provides the core instruction set for an LLM to repair YAML with indentation errors. It is designed to be wrapped in your application's retry harness, receiving the original malformed YAML, the validation error, and an optional schema. The prompt forces the model to act as a strict syntax corrector, not a content editor, ensuring all key-value data is preserved.

yamlCopy
system: |
  You are a YAML repair engine. Your only job is to fix indentation and whitespace errors in the provided YAML document.
  You must preserve all key-value pairs, comments, and anchors exactly as provided.
  Do not add, remove, or reorder any keys or values.
  Do not change any scalar values, including strings, numbers, or booleans.
  Normalize all indentation to consistent spaces (never tabs).
  If a [YAML_SCHEMA] is provided, ensure the repaired output validates against it.
  If the document contains fatal structural errors that cannot be reliably repaired, output a JSON error object instead of guessing.

human: |
  Repair the indentation and whitespace errors in the YAML document below.

  Validation Error:
  [VALIDATION_ERROR]

  Malformed YAML:
  [MALFORMED_YAML]

  Schema (optional):
  [YAML_SCHEMA]

  Output only the corrected YAML. If repair is impossible, output a JSON object with the key "repair_error" and a "reason" field.

To adapt this template, replace the placeholders with your runtime data. [MALFORMED_YAML] is the raw string that failed parsing. [VALIDATION_ERROR] is the exact error message from your YAML parser (e.g., PyYAML, yaml.v3). [YAML_SCHEMA] is an optional JSON Schema or similar structural definition. If you don't have a schema, remove that line from the human message and the corresponding instruction from the system prompt. The final instruction to output a JSON error object on fatal failure is critical for preventing the model from hallucinating a plausible but incorrect YAML document when the input is too damaged to fix.

This prompt is designed to be the core logic within a retry-and-repair harness, not a standalone chat interaction. The typical integration point is a post-inference validation step in a pipeline that generates or modifies YAML files, such as a Kubernetes manifest generator, a CI/CD config writer, or an infrastructure-as-code assistant. When the primary model output fails a strict YAML linter or schema validator, the harness should catch the error, package the failed YAML and the specific error messages, and invoke this recovery prompt. The goal is to produce a clean, schema-compliant YAML document without losing the semantic content of the original, flawed output.

To implement this, wrap the prompt template in a function that accepts three inputs: the raw, invalid YAML string, a list of structured error objects from your linter (e.g., yamllint or js-yaml), and an optional YAML schema definition. The function should construct the [INVALID_YAML] and [ERROR_CONTEXT] placeholders precisely. For [ERROR_CONTEXT], format each error as a single line: Line [L]: [Error Message]. The harness must then call the LLM with this assembled prompt. On receiving the response, extract the corrected_yaml field from the JSON output. Do not trust the output yet. Immediately run the extracted YAML through the same linter and schema validator that triggered the recovery. If it passes, the repair is successful. If it fails, you have two choices: feed the new error back into the prompt for a second attempt (up to a defined retry budget, typically 2-3 attempts), or escalate to a human operator with the original and all attempted repairs logged.

For production use, implement strict guardrails around this loop. Log every attempt, including the original invalid YAML, the error context sent to the model, the raw model response, and the final validation result. This audit trail is critical for debugging systemic prompt failures or model drift. Use a repair_confidence threshold from the model's output to decide whether to auto-apply the fix or flag it for review. For high-risk environments like production infrastructure changes, always require human approval before applying any auto-repaired YAML, regardless of validation success. Avoid using this prompt for YAML documents that contain sensitive secrets; if you must, ensure the logging pipeline redacts them before persistence.