Broken YAML Document Closure Prompt Template

This prompt is for infrastructure and platform engineers who receive a truncated YAML document from a model and need a valid, parseable YAML file without losing the partial data already generated. The job-to-be-done is post-generation structural repair: the model stopped mid-stream due to a token limit, a connection interruption, or an early stop signal, and you are left with a broken manifest, pipeline definition, or configuration block that must be closed correctly before it can be applied or stored. The prompt instructs the model to act as a YAML-aware repair tool—closing incomplete mappings, sequences, block scalars, and flow styles while preserving every key, value, and comment that was already present in the truncated input.

Use this prompt when the truncated document is structurally incomplete but semantically recoverable—you can see where the break occurred and the remaining partial content is valuable. Ideal inputs include Kubernetes manifests, CI/CD pipeline definitions, Docker Compose files, Ansible playbooks, or any configuration-as-code artifact where losing the partial output would waste significant generation cost. Do not use this prompt when the truncation point is ambiguous (e.g., the output cuts off mid-word in a way that destroys key names), when the document contains sensitive secrets that should not be sent to a model for repair, or when the original generation task was low-confidence and the partial output is likely hallucinated. In those cases, discard the output and regenerate with a higher token limit or a different strategy.

Before wiring this into a production harness, define your acceptance criteria: the repaired YAML must pass a strict parser (e.g., Python's yaml.safe_load), must preserve all original keys and their partial values, and must not introduce new top-level keys or hallucinated data. The next section provides the copy-ready template. After adapting it, proceed to the implementation harness to add validation, retries, and logging before this prompt touches a live pipeline.

This prompt template is designed to be integrated into a post-generation repair loop. When a YAML output is truncated—due to token limits, streaming interruptions, or model early-stopping—this prompt instructs the model to act as a strict syntax-aware closure tool. It must close the document without inventing new keys, altering existing values, or changing the semantic intent of the partial content. The primary goal is to produce a syntactically valid YAML document that a standard parser can load without error.

yamlCopy
system: |
  You are a YAML repair engine. Your only task is to close a truncated YAML document.
  - Do not add, remove, or modify any existing keys or values.
  - Do not infer or hallucinate missing data. If a value is incomplete, leave it as an empty string or null as appropriate for its context.
  - Close all open mappings (`}`), sequences (`]`), and block scalars.
  - Preserve all comments and whitespace structure exactly as they appear in the input.
  - Output ONLY the repaired YAML document. No explanations, no markdown fences.

user: |
  Repair the following truncated YAML. Close all open structures to make it valid.

  [TRUNCATED_YAML_INPUT]

To adapt this template, replace [TRUNCATED_YAML_INPUT] with the raw, truncated string from your model's output. In a production harness, you should wrap this prompt in a retry loop with a strict YAML parser (e.g., Python's yaml.safe_load). If the parser succeeds, the repair is considered complete. If it fails, the error message can be fed back into a subsequent retry prompt. For high-risk infrastructure workflows, always log the original truncated output and the repaired version for auditability before applying any configuration changes.

This prompt is designed as a post-generation repair step, not a standalone generation tool. It should be invoked only after a YAML document has been identified as truncated—typically by catching a yaml.YAMLError or yaml.scanner.ScannerError during parsing. The harness must capture the raw, partial string output from the upstream model, the original task context that generated it, and any schema or structural constraints the final YAML must satisfy. Passing the original task context is critical because the repair model needs to understand the document's purpose to infer correct closures for mappings, sequences, and block scalars rather than guessing syntactically valid but semantically wrong structures.

Wire the prompt into an application as a dedicated repair function that accepts three inputs: the partial YAML string, the original generation prompt or task description, and an optional YAML schema or expected top-level keys list. The function should first validate that the input is genuinely truncated by attempting to parse it; if parsing succeeds, skip the repair call entirely. On parse failure, construct the prompt by injecting the partial content into the [PARTIAL_YAML] placeholder, the original task into [ORIGINAL_TASK], and any known structural constraints into [EXPECTED_STRUCTURE]. Use a model with strong code and configuration understanding—Claude 3.5 Sonnet or GPT-4o are good defaults. Set temperature=0 to minimize creative variation in structural repair. Implement a retry loop with a maximum of 2 repair attempts: if the first repaired output fails YAML parsing, feed the parse error back into a second repair call using the [PARSE_ERROR] placeholder before escalating to human review or logging the failure.

The output of this prompt must pass through a strict validation harness before being accepted. At minimum, validate that the repaired YAML parses successfully using a standard YAML library (PyYAML, ruamel.yaml). Beyond parse success, implement key-preservation checks: extract all top-level keys from the partial input and verify they exist in the repaired output. For Kubernetes manifests or pipeline definitions, add a structural schema check—confirm that required fields like apiVersion, kind, and metadata are present and non-null. Log every repair attempt with the partial input hash, the repair duration, parse success/failure, and key-preservation rate. This telemetry helps identify whether truncation patterns are changing over time or whether the repair model is degrading. For high-risk infrastructure configs, route all repaired outputs to a human approval queue before applying them to any live system.

Common integration pitfalls to avoid: do not use this prompt on YAML that is syntactically valid but semantically incomplete—the model may alter correct structure unnecessarily. Do not skip the original task context; without it, the model will close mappings with empty or placeholder values that break downstream systems. Do not apply repaired YAML directly to production infrastructure without validation. If the partial YAML contains secrets, encrypted values, or sensitive data, redact those fields before sending them to an external model API, or use a locally deployed model. Finally, set a generous max_tokens value for the repair call—at least double the length of the partial input—to ensure the model has enough room to complete the document without introducing a second truncation.