Terraform and OpenTofu Guide
agentscope-ai/QwenPaw
Guidance for writing and testing Terraform and OpenTofu code: module structure, naming, test approaches, CI/CD workflows, state handling and security scanning.
Create, generate, write, or scaffold Terraform .tf HCL — resources, modules, providers, variables, outputs.
$ npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install akin-ozer/cc-devops-skills terraform-generator --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/akin-ozer/cc-devops-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/devops-skills-plugin/skills/terraform-generator .claude/skills/terraform-generator && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "terraform-generator" agent skill from https://github.com/akin-ozer/cc-devops-skills/tree/main/devops-skills-plugin/skills/terraform-generator into .claude/skills/terraform-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "terraform-generator", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/akin-ozer/cc-devops-skills/tree/main/devops-skills-plugin/skills/terraform-generatorType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install akin-ozer/cc-devops-skills terraform-generator --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/akin-ozer/cc-devops-skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/devops-skills-plugin/skills/terraform-generator .agents/skills/terraform-generator && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "terraform-generator" agent skill from https://github.com/akin-ozer/cc-devops-skills/tree/main/devops-skills-plugin/skills/terraform-generator into .agents/skills/terraform-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "terraform-generator", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install akin-ozer/cc-devops-skills terraform-generator --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/akin-ozer/cc-devops-skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/devops-skills-plugin/skills/terraform-generator .cursor/skills/terraform-generator && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "terraform-generator" agent skill from https://github.com/akin-ozer/cc-devops-skills/tree/main/devops-skills-plugin/skills/terraform-generator into .cursor/skills/terraform-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "terraform-generator", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/akin-ozer/cc-devops-skills.git --path devops-skills-plugin/skills/terraform-generator--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install akin-ozer/cc-devops-skills terraform-generator --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/akin-ozer/cc-devops-skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/devops-skills-plugin/skills/terraform-generator .gemini/skills/terraform-generator && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "terraform-generator" agent skill from https://github.com/akin-ozer/cc-devops-skills/tree/main/devops-skills-plugin/skills/terraform-generator into .gemini/skills/terraform-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "terraform-generator", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install akin-ozer/cc-devops-skills terraform-generatorInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/akin-ozer/cc-devops-skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/devops-skills-plugin/skills/terraform-generator .github/skills/terraform-generator && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "terraform-generator" agent skill from https://github.com/akin-ozer/cc-devops-skills/tree/main/devops-skills-plugin/skills/terraform-generator into .github/skills/terraform-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "terraform-generator", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install akin-ozer/cc-devops-skills terraform-generator --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/akin-ozer/cc-devops-skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/devops-skills-plugin/skills/terraform-generator .opencode/skills/terraform-generator && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "terraform-generator" agent skill from https://github.com/akin-ozer/cc-devops-skills/tree/main/devops-skills-plugin/skills/terraform-generator into .opencode/skills/terraform-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "terraform-generator", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
terraform-generatorCreate, generate, write, or scaffold Terraform .tf HCL — resources, modules, providers, variables, outputs.
Terraform Generator is an agent skill from akin-ozer/cc-devops-skills. Create, generate, write, or scaffold Terraform .tf HCL — resources, modules, providers, variables, outputs.
Its SKILL.md is about 7.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 18 other files, including scripts, reference files and assets (for example `assets/README.md`, `assets/minimal-project/README.md` and `references/common_patterns.md`).
It sits in DevOps & Cloud, covering Infrastructure as code. It works with Terraform. The repository describes itself as: DevOps skills for Claude Code and Codex. The licence is Apache-2.0.
6 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 276af75. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Ships 2 files in scripts/ (Shell), which the agent can run.
Shell commands in SKILL.md call:
terraformbashFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Terraform Generator loads about 7.7k tokens when it runs, and up to ~22k if it reads all its reference files. Until then it costs about 32 tokens; SKILL.md has 1,329 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.
The full file from akin-ozer/cc-devops-skills at commit 276af75, republished under its Apache-2.0 licence (© akin-ozer). 1,329 words, ~7,695 tokens.
.claude/skills/terraform-generator/SKILL.md (or your agent's skills folder). This skill also uses 13 other files; get the full folder from GitHub.This skill enables the generation of production-ready Terraform configurations following best practices and current standards. Automatically integrates validation and documentation lookup for custom providers and modules.
STOP: You MUST complete ALL steps in order. Do NOT skip any REQUIRED step.
| Step | Action | Required |
|---|---|---|
| 1 | Understand requirements (providers, resources, modules) | ✅ REQUIRED |
| 2 | Check for custom providers/modules and lookup documentation | ✅ REQUIRED |
| 3 | Consult reference files before generation | ✅ REQUIRED |
| 4 | Generate Terraform files with ALL best practices | ✅ REQUIRED |
| 5 | Include data sources for dynamic values (region, account, AMIs) | ✅ REQUIRED |
| 6 | Add lifecycle rules on critical resources (KMS, databases) | ✅ REQUIRED |
| 7 | Invoke Skill(devops-skills:terraform-validator) | ✅ REQUIRED |
| 8 | FIX all validation/security failures and RE-VALIDATE | ✅ REQUIRED |
| 9 | Provide usage instructions (files, next steps, security) | ✅ REQUIRED |
IMPORTANT: If validation fails (terraform validate OR security scan), you MUST fix the issues and re-run validation until ALL checks pass. Do NOT proceed to Step 9 with failing checks.
When generating Terraform configurations, follow this workflow:
Analyze the user's request to determine:
Before generating configurations, identify if custom or third-party providers/modules are involved:
Standard providers (no lookup needed):
Custom/third-party providers/modules (require documentation lookup):
When custom providers/modules are detected:
Use WebSearch to find version-specific documentation:
Search query format: "[provider/module name] terraform [version] documentation [specific resource]"
Example: "datadog terraform provider v3.30 monitor resource documentation"
Example: "terraform-aws-modules vpc version 5.0 documentation"Focus searches on:
If Context7 MCP is available and the provider/module is supported, use it as an alternative:
mcp__context7__resolve-library-id → mcp__context7__query-docsBefore generating configuration, you MUST consult reference files using this matrix:
| Reference | Requirement | Read When |
|---|---|---|
terraform_best_practices.md | REQUIRED | Always - contains baseline required patterns |
provider_examples.md | REQUIRED | Any AWS, Azure, GCP, or Kubernetes resource generation |
common_patterns.md | OPTIONAL by default, REQUIRED for complex requests | Multi-environment, workspace, composition, DR, or conditional patterns |
Open references by path:
devops-skills-plugin/skills/terraform-generator/references/terraform_best_practices.md
devops-skills-plugin/skills/terraform-generator/references/provider_examples.md
devops-skills-plugin/skills/terraform-generator/references/common_patterns.mdGenerate HCL files following best practices:
File Organization:
terraform-project/
├── main.tf # Primary resource definitions
├── variables.tf # Input variable declarations
├── outputs.tf # Output value declarations
├── versions.tf # Provider version constraints
├── terraform.tfvars # Variable values (optional, for examples)
└── backend.tf # Backend configuration (optional)Best Practices to Follow:
Provider Configuration:
terraform {
required_version = ">= 1.10, < 2.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 6.0" # Major pin; verify exact current version when needed
}
}
}
provider "aws" {
region = var.aws_region
}Resource Naming:
resource "aws_instance" "web_server" {
# ...
}Variable Declarations:
variable "instance_type" {
description = "EC2 instance type for web servers"
type = string
default = "t3.micro"
validation {
condition = contains(["t3.micro", "t3.small", "t3.medium"], var.instance_type)
error_message = "Instance type must be t3.micro, t3.small, or t3.medium."
}
}Output Values:
output "instance_public_ip" {
description = "Public IP address of the web server"
value = aws_instance.web_server.public_ip
}Use Data Sources for References:
data "aws_ami" "ubuntu" {
most_recent = true
owners = ["099720109477"] # Canonical
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
}
}Module Usage:
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "5.0.0"
name = "my-vpc"
cidr = "10.0.0.0/16"
azs = ["us-east-1a", "us-east-1b"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
public_subnets = ["10.0.101.0/24", "10.0.102.0/24"]
}Use locals for Computed Values:
locals {
common_tags = {
Environment = var.environment
ManagedBy = "Terraform"
Project = var.project_name
}
}Lifecycle Rules When Appropriate:
resource "aws_instance" "example" {
# ...
lifecycle {
create_before_destroy = true
prevent_destroy = true
ignore_changes = [tags]
}
}Dynamic Blocks for Repeated Configuration:
resource "aws_security_group" "example" {
# ...
dynamic "ingress" {
for_each = var.ingress_rules
content {
from_port = ingress.value.from_port
to_port = ingress.value.to_port
protocol = ingress.value.protocol
cidr_blocks = ingress.value.cidr_blocks
}
}
}Comments and Documentation:
Security Best Practices:
You MUST include provider-appropriate data lookups for dynamic infrastructure values. Do NOT hardcode cloud/account/region/image IDs.
| Provider | Required Dynamic Context | Typical Data Sources |
|---|---|---|
| AWS | Region/account/AZ/image IDs | aws_region, aws_caller_identity, aws_availability_zones, aws_ami |
| Azure | Tenant/subscription/client context | azurerm_client_config, azurerm_subscription |
| GCP | Project/client context/zone discovery | google_client_config, google_compute_zones, google_compute_image |
| Kubernetes | Cluster endpoint/auth from trusted source | Use module outputs or cloud data sources; avoid hardcoded tokens/endpoints |
# AWS dynamic context
data "aws_region" "current" {}
data "aws_caller_identity" "current" {}
# Azure dynamic context
data "azurerm_client_config" "current" {}
data "azurerm_subscription" "current" {}
# GCP dynamic context
data "google_client_config" "current" {}You MUST protect stateful and critical resources from accidental destruction/deletion using both Terraform lifecycle and provider-native safeguards.
| Provider | Critical Resource Classes | Required Protection Mechanism |
|---|---|---|
| AWS | KMS, RDS, S3 data buckets, DynamoDB, ElastiCache, secrets | lifecycle { prevent_destroy = true } and service-specific deletion protection where supported |
| Azure | Key Vaults, SQL, Storage, stateful compute | prevent_destroy where appropriate plus provider feature flags/resource deletion protection |
| GCP | Cloud SQL, GKE, storage, stateful compute | prevent_destroy and resource-level deletion_protection = true where supported |
| Kubernetes | Stateful workloads and persistent data | Avoid destructive replacement patterns and protect backing cloud resources |
resource "aws_db_instance" "main" {
# ...
deletion_protection = true
lifecycle {
prevent_destroy = true
}
}
resource "google_sql_database_instance" "main" {
# ...
deletion_protection = true
}When using AWS S3 lifecycle configuration, ALWAYS include a rule to abort incomplete multipart uploads:
resource "aws_s3_bucket_lifecycle_configuration" "main" {
bucket = aws_s3_bucket.main.id
# REQUIRED: Abort incomplete multipart uploads to prevent storage costs
rule {
id = "abort-incomplete-uploads"
status = "Enabled"
# Filter applies to all objects (empty filter = all objects)
filter {}
abort_incomplete_multipart_upload {
days_after_initiation = 7
}
}
# Other lifecycle rules (e.g., transition to IA)
rule {
id = "transition-to-ia"
status = "Enabled"
filter {
prefix = "" # Apply to all objects
}
transition {
days = 90
storage_class = "STANDARD_IA"
}
noncurrent_version_transition {
noncurrent_days = 30
storage_class = "STANDARD_IA"
}
noncurrent_version_expiration {
noncurrent_days = 365
}
}
}Why? Incomplete multipart uploads consume storage and incur costs. Checkov check
CKV_AWS_300enforces this for AWS.For Azure/GCP object storage, add equivalent lifecycle/retention rules for stale objects and old versions.
After generating Terraform files, ALWAYS validate them using the devops-skills:terraform-validator skill:
Invoke: Skill(devops-skills:terraform-validator)The devops-skills:terraform-validator skill will:
terraform fmt -checkterraform initterraform validateterraform planCRITICAL: Fix-and-Revalidate Loop
If ANY validation or security check fails, you MUST:
Skill(devops-skills:terraform-validator) again┌─────────────────────────────────────────────────────────┐
│ VALIDATION FAILED? │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────────────┐ │
│ │ Fix │───▶│ Re-run │───▶│ All checks pass? │ │
│ │ Issue │ │ Skill │ │ YES → Step 5 │ │
│ └─────────┘ └─────────┘ │ NO → Loop back │ │
│ ▲ └─────────────────────┘ │
│ │ │ │
│ └────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘Common validation failures to fix:
| Check | Issue | Fix |
|---|---|---|
CKV_AWS_300 | Missing abort multipart upload | Add abort_incomplete_multipart_upload rule |
CKV_AWS_24 | SSH open to 0.0.0.0/0 | Restrict to specific CIDR |
CKV_AWS_16 | RDS encryption disabled | Add storage_encrypted = true |
terraform validate | Invalid resource argument | Check provider documentation |
If custom providers are detected during validation:
After successful generation and validation with ALL checks passing, you MUST provide the user with:
Required Output Format:
## Generated Files
| File | Description |
|------|-------------|
| `<actual-file-path>` | What was generated in that file |
Only list files that were actually generated for this request. Do not include placeholder paths or files that do not exist.
## Next Steps
1. Review and customize `terraform.tfvars` with your values
2. Initialize Terraform:
```bash
terraform initterraform planterraform applyvariable_name in terraform.tfvars⚠️ Before applying:
> **IMPORTANT:** Do NOT skip Step 5. The user needs actionable guidance on how to use the generated configuration.
## Common Generation Patterns
### Pattern 1: Simple Resource Creation
User request: "Create an AWS S3 bucket with versioning"
Generated files:
- `main.tf` - S3 bucket resource with versioning enabled
- `variables.tf` - Bucket name, tags variables
- `outputs.tf` - Bucket ARN and name outputs
- `versions.tf` - AWS provider version constraints
### Pattern 2: Module-Based Infrastructure
User request: "Set up a VPC using the official AWS VPC module"
Actions:
1. Identify module: terraform-aws-modules/vpc/aws
2. Web search for latest version and documentation
3. Generate configuration using module with appropriate inputs
4. Validate with devops-skills:terraform-validator
### Pattern 3: Multi-Provider Configuration
User request: "Create infrastructure across AWS and Datadog"
Actions:
1. Identify standard provider (AWS) and custom provider (Datadog)
2. Web search for Datadog provider documentation with version
3. Generate configuration with both providers properly configured
4. Ensure provider aliases if needed
5. Validate with devops-skills:terraform-validator
### Pattern 4: Complex Resource with Dependencies
User request: "Create an ECS cluster with ALB and auto-scaling"
Generated structure:
- Multiple resource blocks with proper dependencies
- Data sources for AMIs, availability zones, etc.
- Local values for computed configurations
- Comprehensive variables and outputs
- Proper dependency management using implicit references
## Error Handling
**Common Issues and Solutions:**
1. **Provider Not Found:**
- Ensure provider is listed in `required_providers` block
- Verify source address format: `namespace/name`
- Check version constraint syntax
2. **Invalid Resource Arguments:**
- Refer to web search results for custom providers
- Check for required vs optional arguments
- Verify attribute value types (string, number, bool, list, map)
3. **Circular Dependencies:**
- Review resource references
- Use `depends_on` explicit dependencies if needed
- Consider breaking into separate modules
4. **Validation Failures:**
- Run devops-skills:terraform-validator skill to get detailed errors
- Fix issues one at a time
- Re-validate after each fix
## Version Awareness
Always consider version compatibility:
1. **Terraform Version:**
- Use `required_version` constraint with both lower and upper bounds
- If generated configuration includes write-only arguments (`*_wo`): use `required_version = ">= 1.11, < 2.0"`.
- Else if it uses ephemeral constructs (`ephemeral` blocks, ephemeral variables/outputs) without write-only arguments: use `required_version = ">= 1.10, < 2.0"`.
- Else use the project baseline (default `>= 1.8, < 2.0` unless repository policy requires newer).
- Use `>= 1.14, < 2.0` for latest features (actions, query command)
- Document any version-specific features used (see below)
2. **Provider Version Policy (canonical):**
- Pin provider major versions with `~>` constraints (for example `~> 6.0`, `~> 4.0`, `~> 7.0`).
- Do not claim "latest" version unless verified online during the current run.
- Keep cross-provider guidance consistent:
- AWS family: major-pin policy (for example `~> 6.0`)
- AzureRM: major-pin policy (for example `~> 4.0`)
- Google: major-pin policy (for example `~> 7.0`)
- Kubernetes: major/minor pin based on target cluster/provider compatibility
- Use the same provider/version language in `SKILL.md`, `references/terraform_best_practices.md`, and template `assets/minimal-project/versions.tf`.
3. **Module Versions:**
- Always pin module versions
- Review module documentation for version compatibility
- Test module updates in non-production first
### Required Version Decision Table
| Generated Output Contains | Required Version to Emit |
|---------------------------|--------------------------|
| Any write-only argument (`*_wo`) | `>= 1.11, < 2.0` |
| Ephemeral constructs only (no write-only) | `>= 1.10, < 2.0` |
| Neither write-only nor ephemeral | Project baseline (default `>= 1.8, < 2.0`) |
#### Feature-Gating Examples
```hcl
# Positive: write-only usage requires Terraform 1.11+
terraform {
required_version = ">= 1.11, < 2.0"
}
ephemeral "random_password" "db_password" {
length = 16
}
resource "aws_db_instance" "main" {
identifier = "mydb"
instance_class = "db.t3.micro"
allocated_storage = 20
engine = "postgres"
username = "admin"
skip_final_snapshot = true
password_wo = ephemeral.random_password.db_password.result
password_wo_version = 1
}# Negative: reject this pattern (write-only with Terraform 1.10)
terraform {
required_version = ">= 1.10, < 2.0"
}
resource "aws_db_instance" "invalid" {
password_wo = "do-not-generate-this"
}| Feature | Minimum Version |
|---|---|
terraform_data resource | 1.4+ |
import {} blocks | 1.5+ |
check {} blocks | 1.5+ |
Native testing (.tftest.hcl) | 1.6+ |
| Test mocking | 1.7+ |
removed {} blocks | 1.7+ |
| Provider-defined functions | 1.8+ |
| Cross-type refactoring | 1.8+ |
| Enhanced variable validations | 1.9+ |
templatestring function | 1.9+ |
| Ephemeral resources | 1.10+ |
| Write-only arguments | 1.11+ |
| S3 native state locking | 1.11+ |
Import blocks with for_each | 1.12+ |
| Actions block | 1.14+ |
List resources (tfquery.hcl) | 1.14+ |
terraform query command | 1.14+ |
Provider-defined functions extend Terraform's built-in functions with provider-specific logic.
Syntax: provider::<provider_name>::<function_name>(arguments)
# AWS Provider Functions (v5.40+)
locals {
# Parse an ARN into components
parsed_arn = provider::aws::arn_parse(aws_instance.web.arn)
account_id = local.parsed_arn.account
region = local.parsed_arn.region
# Build an ARN from components
custom_arn = provider::aws::arn_build({
partition = "aws"
service = "s3"
region = ""
account = ""
resource = "my-bucket/my-key"
})
}
# Google Cloud Provider Functions (v5.23+)
locals {
# Extract region from zone
region = provider::google::region_from_zone(var.zone) # "us-west1-a" → "us-west1"
}
# Kubernetes Provider Functions (v2.28+)
locals {
# Encode HCL to Kubernetes manifest YAML
manifest_yaml = provider::kubernetes::manifest_encode(local.deployment_config)
}Ephemeral resources provide temporary values that are never persisted in state or plan files. Critical for handling secrets securely.
# Generate a password that never touches state
ephemeral "random_password" "db_password" {
length = 16
special = true
override_special = "!#$%&*()-_=+[]{}<>:?"
}
# Fetch secrets ephemerally from AWS Secrets Manager
ephemeral "aws_secretsmanager_secret_version" "api_key" {
secret_id = aws_secretsmanager_secret.api_key.id
}
# Ephemeral variables (declare with ephemeral = true)
variable "temporary_token" {
type = string
ephemeral = true # Value won't be stored in state
}
# Ephemeral outputs
output "session_token" {
value = ephemeral.aws_secretsmanager_secret_version.api_key.secret_string
ephemeral = true # Won't be stored in state
}Write-only arguments accept ephemeral values and are never persisted. They use _wo suffix and require a version attribute.
terraform {
required_version = ">= 1.11, < 2.0"
}
# Secure database password handling
ephemeral "random_password" "db_password" {
length = 16
}
resource "aws_db_instance" "main" {
identifier = "mydb"
instance_class = "db.t3.micro"
allocated_storage = 20
engine = "postgres"
username = "admin"
# Write-only password - never stored in state!
password_wo = ephemeral.random_password.db_password.result
password_wo_version = 1 # Increment to trigger password rotation
skip_final_snapshot = true
}
# Secrets Manager with write-only
resource "aws_secretsmanager_secret_version" "db_password" {
secret_id = aws_secretsmanager_secret.db_password.id
# Write-only secret string
secret_string_wo = ephemeral.random_password.db_password.result
secret_string_wo_version = 1
}Validation conditions can now reference other variables, data sources, and local values.
# Reference data sources in validation
data "aws_ec2_instance_type_offerings" "available" {
filter {
name = "location"
values = [var.availability_zone]
}
}
variable "instance_type" {
type = string
description = "EC2 instance type"
validation {
# NEW: Can reference data sources
condition = contains(
data.aws_ec2_instance_type_offerings.available.instance_types,
var.instance_type
)
error_message = "Instance type ${var.instance_type} is not available in the selected AZ."
}
}
# Cross-variable validation
variable "min_instances" {
type = number
default = 1
}
variable "max_instances" {
type = number
default = 10
validation {
# NEW: Can reference other variables
condition = var.max_instances >= var.min_instances
error_message = "max_instances must be >= min_instances"
}
}S3 now supports native state locking without DynamoDB.
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "project/terraform.tfstate"
region = "us-east-1"
encrypt = true
# NEW: S3-native locking (Terraform 1.11+)
use_lockfile = true
# DEPRECATED: DynamoDB locking (still works but no longer required)
# dynamodb_table = "terraform-locks"
}
}Declarative resource imports without command-line operations.
# Import existing resources declaratively
import {
to = aws_instance.web
id = "i-1234567890abcdef0"
}
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
# ... configuration must match existing resource
}
# Import with for_each
import {
for_each = var.existing_bucket_names
to = aws_s3_bucket.imported[each.key]
id = each.value
}Safely refactor resources without destroying them.
# Rename a resource
moved {
from = aws_instance.old_name
to = aws_instance.new_name
}
# Move to a module
moved {
from = aws_vpc.main
to = module.networking.aws_vpc.main
}
# Cross-type refactoring (1.8+)
moved {
from = null_resource.example
to = terraform_data.example
}
# Remove resource from state without destroying (1.7+)
removed {
from = aws_instance.legacy
lifecycle {
destroy = false # Keep the actual resource, just remove from state
}
}Import multiple resources using for_each meta-argument.
# Import multiple S3 buckets using a map
locals {
buckets = {
"staging" = "bucket1"
"uat" = "bucket2"
"prod" = "bucket3"
}
}
import {
for_each = local.buckets
to = aws_s3_bucket.this[each.key]
id = each.value
}
resource "aws_s3_bucket" "this" {
for_each = local.buckets
}
# Import across module instances using list of objects
locals {
module_buckets = [
{ group = "one", key = "bucket1", id = "one_1" },
{ group = "one", key = "bucket2", id = "one_2" },
{ group = "two", key = "bucket1", id = "two_1" },
]
}
import {
for_each = local.module_buckets
id = each.value.id
to = module.group[each.value.group].aws_s3_bucket.this[each.value.key]
}Actions enable provider-defined operations outside the standard CRUD model. Use for operations like Lambda invocations, cache invalidations, or database backups.
# Invoke a Lambda function (example syntax)
action "aws_lambda_invoke" "process_data" {
function_name = aws_lambda_function.processor.function_name
payload = jsonencode({ action = "process" })
}
# Create CloudFront invalidation
action "aws_cloudfront_create_invalidation" "invalidate_cache" {
distribution_id = aws_cloudfront_distribution.main.id
paths = ["/*"]
}
# Actions support for_each
action "aws_lambda_invoke" "batch_process" {
for_each = toset(["task1", "task2", "task3"])
function_name = aws_lambda_function.processor.function_name
payload = jsonencode({ task = each.value })
}Triggering Actions via Lifecycle:
Use action_trigger within a resource's lifecycle block to automatically invoke actions:
resource "aws_lambda_function" "example" {
function_name = "my-function"
# ... other config ...
lifecycle {
action_trigger {
events = [after_create, after_update]
actions = [action.aws_lambda_invoke.process_data]
}
}
}
action "aws_lambda_invoke" "process_data" {
function_name = aws_lambda_function.example.function_name
payload = jsonencode({ action = "initialize" })
}Manual Invocation:
Actions can also be invoked manually via CLI:
terraform apply -invoke action.aws_lambda_invoke.process_dataQuery and filter existing infrastructure using .tfquery.hcl files and the terraform query command.
# my-resources.tfquery.hcl
# Define list resources to query existing infrastructure
list "aws_instance" "web_servers" {
filter {
name = "tag:Environment"
values = [var.environment]
}
include_resource = true # Include full resource details
}
list "aws_s3_bucket" "data_buckets" {
filter {
name = "tag:Purpose"
values = ["data-storage"]
}
}# Query infrastructure and output results
terraform query
# Generate import configuration from query results
terraform query -generate-config-out="import_config.tf"
# Output in JSON format
terraform query -json
# Use with variables
terraform query -var 'environment=prod'Add custom validation within resource lifecycle.
resource "aws_instance" "example" {
instance_type = "t3.micro"
ami = data.aws_ami.example.id
lifecycle {
# Check before creation
precondition {
condition = data.aws_ami.example.architecture == "x86_64"
error_message = "The selected AMI must be for the x86_64 architecture."
}
# Verify after creation
postcondition {
condition = self.public_dns != ""
error_message = "EC2 instance must be in a VPC that has public DNS hostnames enabled."
}
}
}
# Preconditions on outputs
output "web_url" {
value = "https://${aws_instance.web.public_dns}"
precondition {
condition = aws_instance.web.public_dns != ""
error_message = "Instance must have a public DNS name."
}
}The references/ directory contains detailed documentation for reference:
terraform_best_practices.md - Comprehensive best practices guidecommon_patterns.md - Common Terraform patterns and examplesprovider_examples.md - Example configurations for popular providersOpen a reference directly by relative path:
devops-skills-plugin/skills/terraform-generator/references/[filename].mdThe assets/ directory contains template files:
minimal-project/ - Minimal Terraform project templateTemplates can be copied and customized for the user's specific needs.
bash scripts/run_ci_checks.sh© akin-ozer, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 13 other files (scripts, references, assets) in devops-skills-plugin/skills/terraform-generator of akin-ozer/cc-devops-skills.
Open the folder on GitHubat commit 276af75
Terraform Generator next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Terraform Generator this skillakin-ozer/cc-devops-skills | 320 | — | ~7.7k | Automated safety check: Pass | Apache-2.0 | |
| Terraform and OpenTofu Guideagentscope-ai/QwenPaw | 36k | 6 repos | ~4.2k | Automated safety check: Pass | Apache-2.0 | |
| Terraform Skillantonbabenko/terraform-skill | 2.4k | 1 repos | ~5.1k | Automated safety check: Pass | Apache-2.0 | |
| Review Docshashicorp/terraform-provider-aws | 11k | — | ~1.3k | Automated safety check: Pass | MPL-2.0 | |
| Senior DevOps Toolkitmaslennikov-ig/claude-code-orchestrator-kit | 260 | 6 repos | ~1.1k | Automated safety check: Notes | Custom licence | |
| Cloudflarehodgef/apiker | 127 | 7 repos | ~2.2k | Automated safety check: Pass | MIT |
agentscope-ai/QwenPaw
Guidance for writing and testing Terraform and OpenTofu code: module structure, naming, test approaches, CI/CD workflows, state handling and security scanning.
antonbabenko/terraform-skill
A skill your agent uses when writing, reviewing, or debugging Terraform/OpenTofu modules, tests, CI, scans, or state ops - diagnoses failure mode (identity churn, secrets, blast radius, CI drift…
hashicorp/terraform-provider-aws
Review a Terraform AWS Provider PR's end-user documentation (website/docs//.markdown): whether docs are needed, description openings, argument/attribute style, section structure, tags wording, code…
maslennikov-ig/claude-code-orchestrator-kit
Comprehensive DevOps skill for CI/CD, infrastructure automation, containerization, and cloud platforms (AWS, GCP, Azure). Includes pipeline setup…
hodgef/apiker
Comprehensive Cloudflare platform skill covering Workers, Pages, storage (KV, D1, R2), AI (Workers AI, Vectorize, Agents SDK), feature flags (Flagship), networking (Tunnel, Spectrum), security (WAF…
patrickchugh/terravision
Draw cloud architecture diagrams for AWS, Azure or GCP with the official provider icon sets, using TerraVision.
akin-ozer/cc-devops-skills
Create, generate, or scaffold GitHub Actions workflows, action.yml, or .github/workflows CI/CD pipelines.
akin-ozer/cc-devops-skills
Create, scaffold, or generate Helm charts, Chart.yaml, values.yaml, templates, helpers.
akin-ozer/cc-devops-skills
Generate/create/scaffold Jenkinsfile — declarative, scripted, shared library, CI/CD pipelines.
akin-ozer/cc-devops-skills
Validate, lint, audit, or scan a Dockerfile for security and best practices.
akin-ozer/cc-devops-skills
Validate, lint, audit, fix GitHub Actions workflows (.github/workflows).
akin-ozer/cc-devops-skills
Validate, lint, audit, or check Jenkinsfiles and shared libraries.
Works with
Categories
Create, generate, write, or scaffold Terraform .tf HCL — resources, modules, providers, variables, outputs. Terraform Generator is an agent skill from akin-ozer/cc-devops-skills.tf HCL — resources, modules, providers, variables, outputs.
Terraform Generator fits situations like: tasks that involve Infrastructure as code.
Run `npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a claude-code`. Or copy the skill folder (devops-skills-plugin/skills/terraform-generator in akin-ozer/cc-devops-skills) into .claude/skills/terraform-generator in your project. Claude Code loads it when a task matches its description.
Run `npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a codex`. Or copy the skill folder (devops-skills-plugin/skills/terraform-generator in akin-ozer/cc-devops-skills) into .agents/skills/terraform-generator in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add akin-ozer/cc-devops-skills --skill terraform-generator -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/terraform-generator, .gemini/skills/terraform-generator, .github/skills/terraform-generator and .opencode/skills/terraform-generator in your project.
Going by SKILL.md and its folder, Terraform Generator needs a shell for the scripts in its folder and the command-line tools its instructions call (terraform and bash). Our summary lists: A Bash shell.
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.
Terraform Generator is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 7.7k tokens (SKILL.md is roughly 31k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 14k tokens, read only when the agent opens those files.
Skills that share tags, products or a category with Terraform Generator: Terraform and OpenTofu Guide (agentscope-ai/QwenPaw, 36k stars), Terraform Skill (antonbabenko/terraform-skill, 2.4k stars), Review Docs (hashicorp/terraform-provider-aws, 11k stars) and Senior DevOps Toolkit (maslennikov-ig/claude-code-orchestrator-kit, 260 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
akin-ozer (a GitHub user) maintains it in akin-ozer/cc-devops-skills, which has 320 GitHub stars. The repository holds 30 skills in this directory. The repository was last updated on July 26, 2026.
Source: akin-ozer/cc-devops-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.