# Terraform

> Write, review, refactor, validate, and test modern Terraform configuration while loading release-specific guidance newer than the model's knowledge cutoff. Use for any task involving Terraform or HCL configuration, modules, providers, state, plans, tests, or CLI workflows.

- Skill: `cedws/terraform` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add cedws/terraform`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cedws/terraform/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: cedws (https://skillmd.com/u/cedws)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cedws/terraform

---


# Terraform

## Load release supplements

Determine the Terraform version governing the files in scope before making version-specific decisions:

1. Read the `required_version` constraint in the root module's `terraform` block. Treat its lowest permitted minor release as the target when it establishes one.
2. If the configuration does not establish a lower bound, read `.terraform-version` or an equivalent version-manager file that applies to the root module.
3. If neither source establishes a version, run `terraform version -json` and read `terraform_version`.
4. If no local source establishes a version, use an explicit version from the user's request. Otherwise ask for the target instead of assuming one.

Determine the model's knowledge cutoff. Compare the target Terraform version and cutoff with the release table, then load every listed sibling skill whose version is at or below the target and whose release falls after the cutoff. Load selected skills oldest first.

| Terraform version | Release date | Skill |
| --- | --- | --- |
| 1.5 | 2023-06-12 | `terraform-1-5` |
| 1.6 | 2023-10-04 | `terraform-1-6` |
| 1.7 | 2024-01-17 | `terraform-1-7` |
| 1.8 | 2024-04-10 | `terraform-1-8` |
| 1.9 | 2024-06-26 | `terraform-1-9` |
| 1.10 | 2024-11-27 | `terraform-1-10` |
| 1.11 | 2025-02-27 | `terraform-1-11` |
| 1.12 | 2025-05-14 | `terraform-1-12` |
| 1.13 | 2025-08-20 | `terraform-1-13` |
| 1.14 | 2025-11-19 | `terraform-1-14` |
| 1.15 | 2026-04-29 | `terraform-1-15` |

## Configuration style

Run `terraform fmt` on changed Terraform files. Preserve established module structure and naming conventions when they are clear.

Declare Terraform and provider requirements explicitly in reusable root modules. Give every provider its full source address and a constraint that allows compatible patch releases without silently crossing an unreviewed major version.

```hcl
terraform {
  required_version = ">= 1.15.0, < 2.0.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}
```

Prefer typed variables with validation where invalid inputs can be rejected before provider operations. Mark secret-bearing variables and outputs as `sensitive`; never place credentials or secret values in configuration defaults.

Use locals to name a meaningful derived value or remove genuine repetition. Keep a one-use expression inline when extracting it would obscure the resource configuration.

Prefer `for_each` with stable domain keys when resource instances have durable identities. Use `count` for interchangeable instances whose positional identity is intentional.

Keep provider configuration in root modules. Pass providers into child modules explicitly only when aliases or non-default mappings require it.

Treat state as sensitive operational data. Do not edit state files directly. Use configuration-driven refactoring and import features when the target version supports them; use state commands only when no declarative workflow fits.

Use `depends_on` only for dependencies Terraform cannot infer from value references. Avoid provisioners unless the operation cannot be expressed through a provider, image build, cloud-init, or configuration-management system.

Use lifecycle arguments only for a specific invariant. Do not add `ignore_changes` to conceal perpetual drift without explaining and verifying the external owner of the ignored attribute.

## Verification

Run the narrowest non-mutating checks that cover the change:

1. Run `terraform fmt -check` for formatting-only verification.
2. Run `terraform init -backend=false` when provider or module installation is needed for validation and backend access is not required.
3. Run `terraform validate` after initialisation.
4. Run relevant `terraform test` files for modules that provide tests.
5. Run `terraform plan` only when credentials, backend access, and the selected workspace are known to be safe. Never apply unless the user explicitly requests it.