Terraform HCL Configuration Block Repair Prompt

This prompt is for infrastructure engineers and platform teams who receive model-generated Terraform configurations that fail terraform validate or terraform plan. It repairs syntax errors, missing required arguments, block structure violations, and resource dependency issues in HCL. Use this prompt when a model has produced a configuration that is structurally close to valid but contains specific, identifiable errors that prevent parsing or planning. This is a post-generation repair step, not a configuration generation prompt. It assumes you already have a malformed HCL block and the corresponding error output from Terraform's own validation tooling. The prompt instructs the model to act as a strict repair agent: it must not add new resources, change resource names, or alter the intended infrastructure topology. It must only fix what is broken and return a valid, parseable HCL block.

The ideal workflow wires this prompt into a CI/CD pipeline or an internal platform API. After an initial model generates a Terraform configuration, run terraform validate or terraform plan. If the command exits with a non-zero status, capture the malformed HCL and the exact error output. Feed both into this prompt as [MALFORMED_HCL] and [TERRAFORM_ERROR_OUTPUT]. The model returns a repaired HCL block. You must then run terraform validate on the repaired output before accepting it. If validation fails again, you can retry once with the new error output, but set a hard limit of two repair attempts before escalating to a human operator. Never apply a repaired configuration without a passing terraform plan review.

Do not use this prompt when the model has hallucinated entire resources that don't exist, invented provider features, or produced a configuration that is semantically wrong but syntactically valid. This prompt cannot fix logic errors like wrong CIDR blocks, incorrect IAM policy bindings, or security group rules that open unintended ports. It also cannot recover configurations that are so badly malformed that the original intent is unreadable. In those cases, discard the output and regenerate from the original intent prompt. This prompt is a precision repair tool, not a garbage collector. Use it when the error is specific, the fix is local, and the infrastructure topology is already correct.

This prompt template is designed to be pasted directly into your repair harness. It accepts a broken or invalid Terraform HCL block, the specific error output from terraform validate, and optional context about the intended infrastructure. The model is instructed to act as a strict HCL syntax and structure repair agent, not a creative infrastructure designer. It must produce a corrected block that passes validation without introducing new resources, changing resource types, or hallucinating arguments that were not present in the original broken input.

textCopy
You are an HCL repair agent. Your only job is to fix Terraform configuration blocks so they pass `terraform validate`.

## INPUT
[BROKEN_HCL_BLOCK]

## VALIDATION ERROR
[VALIDATION_ERROR_OUTPUT]

## PROVIDER CONTEXT
Provider: [PROVIDER_NAME]
Provider Version: [PROVIDER_VERSION]

## REPAIR RULES
1. Fix only the errors reported in the validation output. Do not restructure working parts of the configuration.
2. Never change resource types, names, or identifiers.
3. Never add new resources, data sources, or provider blocks.
4. If a required argument is missing, add it with a placeholder value wrapped in angle brackets: <REQUIRED>.
5. If an argument value is invalid, correct it to the nearest valid value based on the provider documentation for version [PROVIDER_VERSION].
6. Preserve all existing comments unless they interfere with syntax repair.
7. If the block contains resource dependencies (depends_on, references to other resources), verify they reference resources that exist in the provided context. Flag unresolvable references in a `## DEPENDENCY_WARNINGS` section.
8. Output only the repaired HCL block and the dependency warnings section. No explanations, no markdown fences around the HCL.

## OUTPUT FORMAT
```hcl
<repaired_hcl_block>

DEPENDENCY_WARNINGS

• <warning_item> or "No dependency issues detected."

CONSTRAINTS

• Do not explain your changes.
• Do not add commentary outside the output format.
• If the block cannot be repaired with the information provided, output ## REPAIR_FAILED followed by the specific reason.

To adapt this template, replace the square-bracket placeholders with your actual values. [BROKEN_HCL_BLOCK] should contain the raw, malformed HCL. [VALIDATION_ERROR_OUTPUT] must be the exact error text from terraform validate—this is critical because the model uses error line numbers and messages to target its repairs. [PROVIDER_NAME] and [PROVIDER_VERSION] ground the model in the correct provider schema, reducing hallucinations of nonexistent arguments. If you are repairing a block that references other resources in the same module, include those resource definitions in [BROKEN_HCL_BLOCK] or supply them as additional context so the dependency check in rule 7 can function. For high-risk infrastructure changes, always run the repaired output through terraform plan in a non-production workspace and require human approval before apply.

This prompt is designed to sit inside a post-generation repair loop, not as a standalone chat interaction. The typical integration point is a CI/CD pipeline or infrastructure-as-code automation workflow where a model generates or modifies Terraform configurations and the output fails terraform validate or terraform plan. Instead of discarding the output, the failed HCL block and the validation error are passed to this prompt for structured repair. The harness must capture the original model output, the exact terraform validate error message, the target provider and resource type context, and any known variable values or module references before invoking the repair prompt.

The implementation loop follows a strict sequence: (1) capture the raw model-generated HCL and run terraform validate -json to get structured error output; (2) extract the failing block, the error message, and the line number range; (3) assemble the prompt with [FAILED_HCL_BLOCK], [VALIDATION_ERROR], [PROVIDER_CONTEXT], and [RESOURCE_CONSTRAINTS]; (4) call the model with a low temperature (0.0–0.2) to maximize deterministic repair behavior; (5) parse the repaired HCL from the response, write it to a temporary .tf file, and re-run terraform validate; (6) if validation passes, run terraform plan to check for unexpected resource changes or dependency breaks; (7) if validation fails again, increment a retry counter and re-invoke the prompt with the new error—stop after three retries and escalate to a human operator. Each repair attempt must be logged with the input error, the model's response, and the validation result for auditability.

For high-risk environments—production infrastructure, stateful resources, or security group changes—add a mandatory human approval gate after successful validation but before terraform apply. The harness should generate a diff between the original failed HCL and the repaired version, present it alongside the terraform plan output, and require explicit approval. Do not auto-apply repaired configurations to production without review. For lower-risk environments like development namespaces or ephemeral test infrastructure, you can auto-apply after validation and plan pass, but still log the full repair chain. Model choice matters: use a model with strong code generation capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) and avoid small or general-purpose models that may introduce new syntax errors during repair. If your workflow uses OpenTofu instead of Terraform, substitute tofu validate in the validation gate—the prompt structure remains identical.