Terraform Patterns

What This Skill Does

This skill helps users write well-structured, secure, and production-grade Terraform code. It provides guidance on module design, state management, security hardening, and CI/CD integration. It's designed for those who want to avoid common Terraform pitfalls and create maintainable infrastructure.

When to Use

Review Terraform code for anti-patterns. Design or refactor a Terraform module. Audit Terraform code for security vulnerabilities. Set up remote state backend. Implement multi-region Terraform deployment. Establish a Terraform CI/CD pipeline.

Key Features

Analyzes Terraform code for anti-patterns. Designs Terraform modules with proper inputs/outputs. Audits Terraform code for security vulnerabilities. Provides guidance on Terraform state management. Offers best practices for module structure. Supports Terraform CI/CD pipeline setup.

Manual Installation

Manual installation

Slash Commands

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

Generate report python3 scripts/tf_module_analyzer.py ./terraform

Run security scan python3 scripts/tf_security_scanner.py ./terraform

/terraform:module — Module Design

Identify module scope

• Single responsibility: one module = one logical grouping
• Determine inputs (variables), outputs, and resource boundaries
• Decide: flat module (single directory) vs nested (calling child modules)

Apply module design checklist

STRUCTURE ├── main.tf — Primary resources ├── variables.tf — All input variables with descriptions and types ├── outputs.tf — All outputs with descriptions ├── versions.tf — terraform {} block with required_providers ├── locals.tf — Computed values and naming conventions ├── data.tf — Data sources (if any) └── README.md — Usage examples and variable documentation

VARIABLES ├── Every variable has: description, type, validation (where applicable) ├── Sensitive values marked: sensitive = true ├── Defaults provided for optional settings ├── Use object types for related settings: variable "config" { type = object({...}) } └── Validate with: validation { condition = ... }

OUTPUTS ├── Output IDs, ARNs, endpoints — things consumers need ├── Include description on every output ├── Mark sensitive outputs: sensitive = true └── Don't output entire resources — only specific attributes

COMPOSITION ├── Root module calls child modules ├── Child modules never call other child modules ├── Pass values explicitly — no hidden data source lookups in child modules ├── Provider configuration only in root module └── Use module "name" { source = "./modules/name" }

Generate module scaffold

• Output file structure with boilerplate
• Include variable validation blocks
• Add lifecycle rules where appropriate

/terraform:security — Security Audit

Code-level audit

State security audit

Generate security report python3 scripts/tf_security_scanner.py ./terraform python3 scripts/tf_security_scanner.py ./terraform --output json

Tooling

scripts/tf_module_analyzer.py

CLI utility for analyzing Terraform directory structure and module quality.

Features: Resource and data source counting Variable and output analysis (missing descriptions, types, validation) Naming convention checks Module composition detection File structure validation JSON and text output

Usage:

Analyze a Terraform directory

python3 scripts/tf_module_analyzer.py ./terraform

JSON output python3 scripts/tf_module_analyzer.py ./terraform --output json

Analyze a specific module python3 scripts/tf_module_analyzer.py ./modules/vpc

scripts/tf_security_scanner.py

CLI utility for scanning .tf files for common security issues.