← ClaudeAtlas

terraformlisted

Stack context for Terraform/IaC projects — module structure, state management, and GCP/AWS provider conventions
SilviaAre95/wayworks · ★ 1 · DevOps & Infrastructure · score 77
Install: claude install-skill SilviaAre95/wayworks
# Stack Profile: Terraform This profile is automatically loaded when working in a Terraform project. ## Project Structure ``` environments/ ├── dev/ │ ├── main.tf │ ├── variables.tf │ ├── outputs.tf │ ├── terraform.tfvars │ └── backend.tf ├── staging/ └── prod/ modules/ ├── networking/ │ ├── main.tf │ ├── variables.tf │ └── outputs.tf ├── compute/ └── database/ ``` ## Conventions ### Naming - Resources: `<provider>_<resource>` with descriptive names - Variables: snake_case, descriptive (`database_instance_tier`, not `tier`) - Outputs: match the resource attribute name - Modules: singular noun (`networking`, not `networks`) ### State Management - Remote state in GCS bucket or S3 with locking (DynamoDB for AWS) - One state file per environment - Never edit state manually — use `terraform state mv/rm` - State bucket has versioning enabled ### Modules - Keep modules small and focused (one concern per module) - All variables have `description` and `type` - Use `validation` blocks for variable constraints - Outputs expose only what consumers need - Pin module versions in `source` attribute ### Security - No secrets in `.tf` files or `.tfvars` - Use `sensitive = true` on secret variables and outputs - IAM: least privilege — don't use `roles/editor` or `roles/owner` - Enable audit logging on sensitive resources - Use service accounts, not user accounts, for automation ## Key Patterns ```hcl # Variables with validation variable "environment" { type =