Terraform infrastructure-as-code agent skill and plugin for Claude Code, Codex, Gemini CLI, Cursor, OpenClaw. Covers module design patterns, state management strategies, provider configuration, security hardening, policy-as-code with Sentinel/OPA, and CI/CD plan/apply workflows. Use when: user wants to design Terraform modules, manage state backends, review Terraform security, implement multi-region deployments, or follow IaC best practices.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
terraform-patterns
description
Terraform infrastructure-as-code agent skill and plugin for Claude Code, Codex, Gemini CLI, Cursor, OpenClaw. Covers module design patterns, state management strategies, provider configuration, security hardening, policy-as-code with Sentinel/OPA, and CI/CD plan/apply workflows. Use when: user wants to design Terraform modules, manage state backends, review Terraform security, implement multi-region deployments, or follow IaC best practices.
Predictable infrastructure. Secure state. Modules that compose. No drift.
Opinionated Terraform workflow that turns sprawling HCL into well-structured, secure, production-grade infrastructure code. Covers module design, state management, provider patterns, security hardening, and CI/CD integration.
Not a Terraform tutorial — a set of concrete decisions about how to write infrastructure code that doesn't break at 3 AM.
Slash Commands
Command
What it does
/terraform:review
Analyze Terraform code for anti-patterns, security issues, and structure problems
/terraform:module
Design or refactor a Terraform module with proper inputs, outputs, and composition
/terraform:security
Audit Terraform code for security vulnerabilities, secrets exposure, and IAM misconfigurations
When This Skill Activates
Recognize these patterns from the user:
"Review this Terraform code"
"Design a Terraform module for..."
"My Terraform state is..."
"Set up remote state backend"
"Multi-region Terraform deployment"
"Terraform security review"
"Module structure best practices"
"Terraform CI/CD pipeline"
Any request involving: .tf files, HCL, Terraform modules, state management, provider configuration, infrastructure-as-code
If the user has .tf files or wants to provision infrastructure with Terraform → this skill applies.
Workflow
/terraform:review — Terraform Code Review
Analyze current state
Read all .tf files in the target directory
Identify module structure (flat vs nested)
Count resources, data sources, variables, outputs
Check naming conventions
Apply review checklist
MODULE STRUCTURE
├── Variables have descriptions and type constraints
├── Outputs expose only what consumers need
├── Resources use consistent naming: {provider}_{type}_{purpose}
├── Locals used for computed values and DRY expressions
└── No hardcoded values — everything parameterized or in locals
STATE & BACKEND
├── Remote backend configured (S3, GCS, Azure Blob, Terraform Cloud)
├── State locking enabled (DynamoDB for S3, native for others)
├── State encryption at rest enabled
├── No secrets stored in state (or state access is restricted)
└── Workspaces or directory isolation for environments
PROVIDERS
├── Version constraints use pessimistic operator: ~> 5.0
├── Required providers block in terraform {} block
├── Provider aliases for multi-region or multi-account
└── No provider configuration in child modules
SECURITY
├── No hardcoded secrets, keys, or passwords
├── IAM follows least-privilege principle
├── Encryption enabled for storage, databases, secrets
├── Security groups are not overly permissive (no 0.0.0.0/0 ingress on sensitive ports)
└── Sensitive variables marked with sensitive = true
provider "aws" {
alias = "production"
region = "us-east-1"
assume_role {
role_arn = "arn:aws:iam::PROD_ACCOUNT_ID:role/TerraformRole"
}
}
State Management Decision Tree
Single developer, small project?
├── Yes → Local state (but migrate to remote ASAP)
└── No
├── Using Terraform Cloud/Enterprise?
│ └── Yes → TF Cloud native backend (built-in locking, encryption, RBAC)
└── No
├── AWS?
│ └── S3 + DynamoDB (encryption, locking, versioning)
├── GCP?
│ └── GCS bucket (native locking, encryption)
├── Azure?
│ └── Azure Blob Storage (native locking, encryption)
└── Other?
└── Consul or PostgreSQL backend
Environment isolation strategy:
├── Separate state files per environment (recommended)
│ ├── Option A: Separate directories (dev/, staging/, prod/)
│ └── Option B: Terraform workspaces (simpler but less isolation)
└── Single state file for all environments (never do this)
CI/CD Integration Patterns
GitHub Actions Plan/Apply
# .github/workflows/terraform.ymlname:Terraformon:pull_request:paths: ['terraform/**']
push:branches: [main]
paths: ['terraform/**']
jobs:plan:runs-on:ubuntu-latestif:github.event_name=='pull_request'steps:-uses:actions/checkout@v4-uses:hashicorp/setup-terraform@v3-run:terraforminit-run:terraformvalidate-run:terraformplan-out=tfplan-run:terraformshow-jsontfplan>plan.json# Post plan as PR commentapply:runs-on:ubuntu-latestif:github.ref=='refs/heads/main'&&github.event_name=='push'environment:productionsteps:-uses:actions/checkout@v4-uses:hashicorp/setup-terraform@v3-run:terraforminit-run:terraformapply-auto-approve
Drift Detection
# Run on schedule to detect driftname:DriftDetectionon:schedule:-cron:'0 6 * * 1-5'# Weekdays at 6 AMjobs:detect:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:hashicorp/setup-terraform@v3-run:terraforminit-run:|
terraform plan -detailed-exitcode -out=drift.tfplan 2>&1 | tee drift.log
EXIT_CODE=$?
if [ $EXIT_CODE -eq 2 ]; then
echo "DRIFT DETECTED — review drift.log"
# Send alert (Slack, PagerDuty, etc.)
fi
Proactive Triggers
Flag these without being asked:
No remote backend configured → Migrate to S3/GCS/Azure Blob with locking and encryption.
Provider without version constraint → Add version = "~> X.0" to prevent breaking upgrades.
Hardcoded secrets in .tf files → Use variables with sensitive = true, or integrate Vault/SSM.
IAM policy with "Action": "*" → Scope to specific actions. No wildcard actions in production.
Security group open to 0.0.0.0/0 on SSH/RDP → Restrict to bastion CIDR or use SSM Session Manager.
No state locking → Enable DynamoDB table for S3 backend, or use TF Cloud.
Resources without tags → Add default_tags in provider block. Tags are mandatory for cost tracking.
Missing prevent_destroy on databases/storage → Add lifecycle block to prevent accidental deletion.
