Terraform Generator

Terraform Generator

Overview

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.

Critical Requirements Checklist

STOP: You MUST complete ALL steps in order. Do NOT skip any REQUIRED step.

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.

Core Workflow

When generating Terraform configurations, follow this workflow:

Step 1: Understand Requirements

Analyze the user's request to determine:

• What infrastructure resources need to be created
• Which Terraform providers are required (AWS, Azure, GCP, custom, etc.)
• Whether any modules are being used (official, community, or custom)
• Version constraints for providers and modules
• Variable inputs and outputs needed
• State backend configuration (local, S3, remote, etc.)

Step 2: Check for Custom Providers/Modules

Before generating configurations, identify if custom or third-party providers/modules are involved:

Standard providers (no lookup needed):

• hashicorp/aws
• hashicorp/azurerm
• hashicorp/google
• hashicorp/kubernetes
• Other official HashiCorp providers

Custom/third-party providers/modules (require documentation lookup):

• Third-party providers (e.g., datadog/datadog, mongodb/mongodbatlas)
• Custom modules from Terraform Registry
• Private or company-specific modules
• Community modules

When custom providers/modules are detected:

1. 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" ``

1. Focus searches on:

• Official documentation (registry.terraform.io, provider websites)
• Required and optional arguments
• Attribute references
• Example usage
• Version compatibility notes

1. If Context7 MCP is available and the provider/module is supported, use it as an alternative: `` mcp__context7__resolve-library-id → mcp__context7__query-docs ``

Step 2.5: Consult Reference Files (REQUIRED)

Before generating configuration, you MUST consult reference files using this matrix:

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.md

Step 3: Generate Terraform Configuration

Generate 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:

1. Provider Configuration: ```hcl 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 }

2. **Resource Naming:**
   - Use descriptive resource names
   - Follow snake_case convention
   - Include resource type in name when helpful

resource "aws_instance" "web_server" {

# ... }

3. **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." } }

4. **Output Values:**

output "instance_public_ip" { description = "Public IP address of the web server" value = aws_instance.web_server.public_ip }

5. **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-*"] } }

6. **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"] }

7. **Use locals for Computed Values:**

locals { common_tags = { Environment = var.environment ManagedBy = "Terraform" Project = var.project_name } }

8. **Lifecycle Rules When Appropriate:**

resource "aws_instance" "example" {

# ...

lifecycle { create_before_destroy = true prevent_destroy = true ignore_changes = [tags] } }

9. **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 } } }

10. **Comments and Documentation:**
    - Add comments explaining complex logic
    - Document why certain values are used
    - Include examples in variable descriptions

**Security Best Practices:**
- Never hardcode sensitive values (use variables)
- Use data sources for AMIs and other dynamic values
- Implement least-privilege IAM policies
- Enable encryption by default
- Use secure backend configurations

### Required: Data Sources for Dynamic Values (Provider-Aware)

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` |