Kubernetes Manifest YAML Repair Prompt Template

This prompt is designed for platform engineers and DevOps practitioners who need to repair model-generated Kubernetes YAML manifests that fail kubectl apply --dry-run=client validation. The job-to-be-done is straightforward: take a malformed manifest and a reference to the last known good state, and produce a syntactically valid, structurally correct manifest that passes a dry-run gate. The ideal user is someone who already understands Kubernetes resource schemas and is integrating an LLM into a GitOps pipeline, a developer self-service portal, or an internal platform that generates infrastructure configuration. You should use this prompt when the model output is structurally broken—indentation errors, apiVersion mismatches, missing or malformed kind fields, or spec structure violations—but the intent of the manifest is still recoverable.

Do not use this prompt when the manifest is syntactically valid but semantically wrong (e.g., a correctly formed Deployment that references a non-existent ConfigMap). That class of error requires a different workflow involving cluster state queries and resource dependency resolution, not structural repair. This prompt also assumes you have a last-known-good manifest or a reference template to diff against. If you are generating manifests from scratch without any reference, use a schema-first generation prompt from the Structured Output and Schema Control pillar instead. The repair prompt works best when the damage is local—a few lines of broken YAML—rather than a completely hallucinated resource definition. For high-risk production environments, always pair this prompt with a kubectl apply --dry-run=server validation step and a human approval gate before the manifest reaches a live cluster.

Before wiring this into your pipeline, ensure you have a reliable way to capture the failed manifest, the validation error message from kubectl, and the last known good version of the same resource. The prompt uses these three inputs to constrain the repair and prevent the model from inventing fields or values that were never present. If you lack a last-known-good manifest, you can substitute a reference template from your organization's approved resource catalog, but be aware that the repair quality will degrade. After running the repair, always diff the output against the last known good manifest to verify that only the broken sections were modified. This diff serves as both a quality check and an audit trail for your change control process.

This prompt template is designed to be copied directly into your application code or prompt management system. It accepts a failed Kubernetes manifest and a kubectl error message, then produces a repaired YAML manifest that passes kubectl apply --dry-run=client validation. The template uses square-bracket placeholders for all variable inputs—replace these with actual values at runtime before sending the prompt to the model.

textCopy
You are a Kubernetes YAML repair specialist. Your task is to fix a malformed Kubernetes manifest that failed `kubectl apply`.

## INPUT
Failed manifest YAML:
```yaml
[FAILED_MANIFEST_YAML]

Error message from kubectl:

codeCopy
[KUBECTL_ERROR_OUTPUT]

CONSTRAINTS

• Output ONLY the repaired YAML manifest inside a single fenced code block labeled yaml.
• Do not include explanations, apologies, or commentary outside the code block.
• Preserve all original resource definitions unless they are structurally invalid.
• Fix the following error classes in priority order:
  1. Indentation errors (tabs, inconsistent spaces, misaligned blocks).
  2. apiVersion mismatches (correct to match the kind field using stable API versions).
  3. kind field errors (case sensitivity, missing kind, invalid kind values).
  4. spec structure violations (missing required fields, wrong field types, invalid nesting).
  5. metadata issues (missing name, invalid labels/annotations format).
• If a field value is ambiguous and cannot be inferred from context, use the placeholder REQUIRES_MANUAL_REVIEW and do not guess.
• Do not add new resources, containers, or configuration that was not present in the original manifest.
• Normalize indentation to 2-space increments.

OUTPUT FORMAT

yamlCopy
[REPAIRED_MANIFEST_YAML]

VALIDATION CHECK

After generating the output, mentally verify:

• Every apiVersion matches the correct group and version for its kind.
• metadata.name is present and follows DNS subdomain naming rules.
• spec contains all required fields for the resource kind.
• Indentation is consistent throughout.

To adapt this template for your environment, replace [FAILED_MANIFEST_YAML] with the raw YAML string that failed validation, and [KUBECTL_ERROR_OUTPUT] with the exact error text returned by kubectl. If you have a last-known-good manifest for the same resource, prepend it as additional context with a ## REFERENCE section to help the model preserve intentional configuration choices. For high-risk production clusters, always route the repaired output through a human approval step before applying—this prompt is a repair aid, not a replacement for cluster change review. Wire the output through a YAML parser and kubectl --dry-run=client in your application harness before accepting the repair as complete.

This prompt is designed to be the final repair step in a kubectl apply failure loop, not a standalone YAML generator. The application harness should catch the initial kubectl error, extract the raw model output and the specific error message, and then invoke this prompt with the [FAILED_MANIFEST] and [KUBECTL_ERROR] placeholders populated. The prompt's primary job is to produce a corrected manifest that passes a --dry-run=client validation gate. Do not use this prompt for generating new manifests from scratch; it is a targeted repair tool for manifests that are structurally close to valid but contain indentation errors, apiVersion mismatches, missing required fields under spec, or incorrect kind values.

The implementation loop should follow a strict sequence: (1) The application receives a model-generated YAML string. (2) It attempts kubectl apply --dry-run=client -f -. (3) On failure, capture the exit code and stderr. (4) If the error is a syntax or schema validation error (not an RBAC or cluster-state error), call the LLM with this repair prompt, injecting the failed manifest and the raw error text. (5) Take the LLM's output and run it through a YAML parser (e.g., Python's yaml.safe_load) to catch basic formatting errors. (6) Re-run kubectl apply --dry-run=client on the repaired output. (7) If the dry-run succeeds, return the repaired manifest to the caller; if it fails again, increment a retry counter. After three failed repair attempts, log the full failure context and escalate to a human operator or a dead-letter queue. Never apply a repaired manifest directly to a live cluster without a successful dry-run gate.

For high-risk environments, add a diff step between the last known good manifest and the repaired output to highlight structural changes. Log every repair attempt with the model's response, the dry-run result, and a diff against the original failed input. Choose a model with strong code and configuration reasoning (e.g., Claude 3.5 Sonnet or GPT-4o) and set the temperature low (0.0–0.1) to minimize creative deviations. Avoid using this harness for manifests that fail due to missing CRDs or cluster-scoped resources; those errors indicate a missing dependency, not a YAML syntax problem, and should be routed to a different resolution workflow.