The best Terraform prompts give the model your provider, your Terraform version and real code, then ask for HCL that passes terraform fmt and terraform validate plus a plan you can check before anything changes. Below are 14 Terraform prompts for ChatGPT, Claude, Claude Code and Codex that cover writing modules, importing existing resources, reviewing plans, refactoring state safely and testing.
They focus on infrastructure as code. For general programming work, see the coding prompts.
How to use these prompts
Copy a prompt, replace the blanks in double braces, or keep the default after the colon: {{provider:AWS}} means AWS unless you change it.
Three habits make Terraform answers much better:
- State the versions. Terraform and provider behavior changes between releases. Put your
required_versionand provider versions in the prompt, or paste yourterraform.tffile. - Paste real code and real output. The model needs the module, the variables and the exact error or plan text. Redact secrets first: the Terraform style guide notes that "The state file can contain secrets and other sensitive information."
- Never skip the plan. Treat every AI answer as a draft. Run
terraform planand read it before you apply. In an agent like Claude Code or Codex, let it run fmt, validate and plan, and keep apply for yourself.
How do you write new Terraform configuration with AI?
1. Write a module that follows the style guide
Use this for a new module. Asking for the file layout and version pins up front saves a cleanup pass.
Write a Terraform module for {{provider:AWS}} that creates {{resource:a private S3 bucket with versioning and server-side encryption}}.
Terraform version: {{tf_version:1.9 or later}}
Provider version: {{provider_version:the current major version}}
Follow the HashiCorp style guide:
- Files: terraform.tf (required_version and required_providers), main.tf, variables.tf, outputs.tf.
- Every variable has a type and a description; optional ones have a sensible default.
- Every output has a description.
- Underscores between words in names; don't repeat the resource type in the name.
- Mark secrets as sensitive.
After the code, list the inputs I must set, and any assumption you made about my account or network.
2. Import resources someone created by hand
For buckets, DNS records or databases created in the console that now need to live in code.
I need to bring existing {{provider:AWS}} resources under Terraform without recreating them.
Resources and their IDs:
{{resources}}
1. Write one import block per resource (to = the resource address, id = the provider's ID).
2. Tell me the exact command to generate draft configuration with terraform plan -generate-config-out, using a file name that doesn't exist yet.
3. When I paste the generated file back, clean it up: remove computed or default-valued arguments, replace hardcoded values that should be variables, and match the naming style of this existing code:
{{example_code}}
Finish with what the plan should show if the import is correct (imports only, no changes, no destroys).
3. Add validation to variables
Bad inputs caught at plan time are cheaper than broken infrastructure.
Add validation blocks to these Terraform variables. For each one, write a condition that catches realistic mistakes and an error_message that tells the user exactly what a valid value looks like.
Rules that apply in my environment: {{rules:environment is dev, staging or prod; names are lowercase with hyphens; CIDR blocks are /16 to /24}}
{{variables}}
Don't add validation that duplicates what the type constraint already checks.
How do you review Terraform with AI before you apply?
4. Review a plan before apply
The most valuable Terraform prompt. Paste the text output of terraform plan, with secrets redacted.
Review this Terraform plan before I apply it to {{environment:production}}.
What I meant to change: {{intent}}
Plan output:
{{plan}}
1. List every resource that will be destroyed or replaced, and the attribute that forces the replacement.
2. Flag anything that doesn't match what I meant to change.
3. Flag changes that could cause downtime or data loss (databases, volumes, DNS, load balancers, IAM).
4. Say clearly whether you'd apply this plan as is, and if not, what to change first.
5. Security and cost review of a module
Use it on a pull request or before you publish a module for other teams.
Review this Terraform code for security and cost problems on {{provider:AWS}}.
Check for: public access that isn't clearly intended, overly broad IAM policies, missing encryption at rest or in transit, security groups open to 0.0.0.0/0, secrets in variables without sensitive = true, missing logging, and resources that are expensive by default.
For each finding: the file and resource, why it matters, the severity (high, medium, low), and the fixed HCL. Don't report style issues.
{{code}}
6. Explain an inherited Terraform codebase
For the repo you just joined. Works best in an agent that can read every file.
Explain this Terraform codebase to an engineer who is new to it.
1. What infrastructure it creates, grouped by purpose.
2. How modules call each other, and which values flow between them.
3. Where state is stored and how environments are separated.
4. Anything risky: hardcoded IDs, unpinned versions, resources that look unused, use of -target in scripts.
{{code_or_paths:read the repo, starting from the root module}}
How do you refactor Terraform state safely?
7. Rename or move resources with moved blocks
Renaming a resource or moving it into a module changes its address. Without a moved block, Terraform plans a destroy and a create.
I'm refactoring this Terraform code: {{change:moving the database resources into a new module called "database"}}.
Current code:
{{code}}
Write the refactored code plus one moved block per resource whose address changes (from = old address, to = new address). Include instances created with count or for_each. Then tell me what the plan should show (moves only, no destroy or create) and what to check if it shows a replacement.
8. Switch from count to for_each without recreating
Removing an item from the middle of a count list shifts every index after it. The for_each docs say to use it "when some instance arguments must have distinct values that can't be directly derived from an integer."
Convert this resource from count to for_each, keyed by {{key:the name of each item}}.
{{code}}
Current list of items in order: {{items}}
Write the new resource, the variable change if needed, and a moved block for every existing instance (from = resource[index], to = resource["key"]) so nothing is destroyed.
9. Stop managing a resource without deleting it
For a resource another team or tool is taking over. The removed block with destroy = false takes it out of state and leaves it running.
I want Terraform to stop managing {{resource_address}} but keep the real resource running, because {{reason:another team now manages it}}.
Current code:
{{code}}
Write the removed block with lifecycle destroy = false, show what to delete from the configuration, and tell me what the plan should say. List anything that references this resource and will break.
10. Investigate drift
For when someone changed infrastructure in the console and the plan shows surprises.
My Terraform plan shows changes I didn't make. I think someone changed resources outside Terraform.
Plan output:
{{plan}}
1. For each change, say whether it looks like drift (changed outside Terraform) or a real change in my code.
2. For drift, give me two options: update the code to match reality, or let Terraform revert it. Say which is safer here.
3. Tell me when terraform plan -refresh-only is the right next step and what it will and won't change.
11. Debug a Terraform error
terraform {{command:plan}} fails with this error.
Error:
{{error}}
Relevant code:
{{code}}
Terraform version: {{tf_version}} | Provider and version: {{provider_version}}
Give the most likely cause first, with the line of evidence from the error. Show the smallest fix. If it could be a provider bug or version mismatch, say how to confirm that.
How do you test and protect Terraform code?
12. Write terraform test files
Terraform tests (v1.6.0 and later) live in .tftest.hcl files. Plan-only runs check logic without creating anything.
Write a terraform test file (.tftest.hcl) for this module.
{{module_code}}
- Use run blocks with command = plan unless a check needs real resources.
- Each run block has assert blocks with a condition and a clear error_message.
- Cover: default inputs, each variable's validation rejecting a bad value (use expect_failures), and the outputs having the expected shape.
- Name each run block after the behavior it checks.
Tell me which checks would need command = apply and real infrastructure to be meaningful.
13. Add lifecycle guards to critical resources
These Terraform resources hold data or serve traffic we can't lose: {{resources:the RDS instance, the S3 bucket with customer uploads, the production DNS zone}}.
{{code}}
Suggest lifecycle settings for each: prevent_destroy where a destroy would be a disaster, create_before_destroy where a replacement would cause downtime, and preconditions or postconditions that catch bad inputs. Explain each choice in one line, and warn me about any setting that will block changes I'll need to make later.
14. Design a CI workflow for Terraform
Design a CI workflow in {{ci:GitHub Actions}} for this Terraform repo.
On a pull request: terraform fmt in check mode, terraform init, terraform validate, terraform test, then terraform plan -out=tfplan, and post a plan summary to the pull request.
On merge to {{branch:main}}: apply the saved plan from the same commit, after a manual approval for {{environment:production}}.
Explain how credentials reach the job without long-lived keys, how you keep the saved plan file private, and how you stop two applies running at once.
Why does the plan matter more than the prompt?
HashiCorp's plan command docs describe the two-step workflow: terraform plan -out=tfplan, then terraform apply tfplan. Saving the plan means you apply exactly what you reviewed. The same page says to "Use -target=ADDRESS in exceptional circumstances only", so be suspicious when an AI answer reaches for -target as a routine fix.
Saved plan files contain full configuration and variable values, so the docs advise treating them as potentially sensitive. Keep them out of chat windows and out of git.
Make your Terraform prompts a skill
If you run the plan review prompt on every change, turn it into a skill so Claude Code or Codex applies it automatically. HashiCorp also publishes an official skill for writing HCL: see the Terraform skill page for what it covers and how to install it. To convert one of the prompts above, paste it into the SKILL.md generator.
Kipt keeps prompts like these as Markdown in a private GitHub repo you own. Blanks such as {{provider:AWS}} stay fillable, you can tag prompts by cloud or team, and ⌘K finds any of them. Skills you save there install into Claude Code or Codex with one npx skills add command.