PluginBench
Skill
Review
Audit score 70

terraform-engineer

jeffallan/claude-skills

Senior Terraform engineer for infrastructure as code across AWS, Azure, and GCP with modular design and state management.

What is terraform-engineer?

This skill provides expert guidance for implementing production-grade infrastructure as code using Terraform. Use it when designing reusable modules, configuring remote state backends, managing multi-environment deployments, and troubleshooting infrastructure validation and plan failures.

  • Design composable, validated Terraform modules with clear input/output interfaces
  • Configure remote backends with locking and encryption for state management
  • Implement provider configuration and version pinning across AWS, Azure, and GCP
  • Validate infrastructure code with terraform fmt, terraform validate, and tflint
  • Troubleshoot state drift, provider authentication, and dependency ordering issues
  • Apply security policies including least privilege, encryption, and secret management

How to install terraform-engineer

npx skills add https://github.com/jeffallan/claude-skills --skill terraform-engineer
Prerequisites
  • Terraform >= 1.5.0 installed locally
  • AWS, Azure, or GCP credentials configured
  • Understanding of HCL syntax and basic Terraform concepts
Claude Code
Cursor
Windsurf
Cline

How to use terraform-engineer

  1. 1.Analyze infrastructure requirements and review existing code or cloud platforms
  2. 2.Design modules with clear variable inputs, validation blocks, and documented outputs
  3. 3.Configure remote backend (S3 + DynamoDB for AWS, or equivalent for Azure/GCP) with encryption and locking enabled
  4. 4.Run terraform fmt to format code, then terraform validate to check syntax
  5. 5.Run tflint to identify rule violations; fix any errors and re-validate until clean
  6. 6.Execute terraform plan -out=tfplan to preview changes, review output carefully
  7. 7.Run terraform apply tfplan to deploy infrastructure; if plan fails, diagnose state drift, auth errors, or dependency issues and retry from validation step

Use cases

Good for
  • Creating reusable infrastructure modules for multi-environment deployments
  • Migrating from local to remote state backends with locking
  • Importing existing cloud resources into Terraform state
  • Resolving state conflicts and drift in production environments
  • Implementing infrastructure testing and policy-as-code validation
Who it's for
  • Infrastructure engineers building infrastructure as code
  • DevOps engineers managing multi-cloud deployments
  • Platform teams creating reusable Terraform modules
  • Cloud architects designing production-grade infrastructure

terraform-engineer FAQ

When should I use this skill?

Use it when implementing infrastructure as code with Terraform, creating reusable modules, managing state backends, configuring providers across clouds, or troubleshooting validation and plan failures.

What cloud providers does this support?

AWS, Azure, and GCP. The skill provides guidance on provider configuration, authentication, and best practices for all three platforms.

How do I handle state drift or conflicts?

Run terraform refresh to reconcile state with real resources, or use terraform state rm / terraform import to realign specific resources. Then re-validate and re-plan before applying.

What validation checks must pass before applying?

Run terraform fmt, terraform validate, and tflint. All must pass cleanly with no errors or violations before proceeding to terraform plan.

Can I store secrets in Terraform code?

No. Never hardcode secrets or store them in plain text. Use environment variables, cloud provider secret managers, or Terraform variables with sensitive=true.

Full instructions (SKILL.md)

Source of truth, from jeffallan/claude-skills.


name: terraform-engineer description: Use when implementing infrastructure as code with Terraform across AWS, Azure, or GCP. Invoke for module development (create reusable modules, manage module versioning), state management (migrate backends, import existing resources, resolve state conflicts), provider configuration, multi-environment workflows, and infrastructure testing. license: MIT metadata: author: https://github.com/Jeffallan version: "1.1.0" domain: infrastructure triggers: Terraform, infrastructure as code, IaC, terraform module, terraform state, AWS provider, Azure provider, GCP provider, terraform plan, terraform apply role: specialist scope: implementation output-format: code related-skills: cloud-architect, devops-engineer, kubernetes-specialist

Terraform Engineer

Senior Terraform engineer specializing in infrastructure as code across AWS, Azure, and GCP with expertise in modular design, state management, and production-grade patterns.

Core Workflow

  1. Analyze infrastructure — Review requirements, existing code, cloud platforms
  2. Design modules — Create composable, validated modules with clear interfaces
  3. Implement state — Configure remote backends with locking and encryption
  4. Secure infrastructure — Apply security policies, least privilege, encryption
  5. Validate — Run terraform fmt and terraform validate, then tflint; if any errors are reported, fix them and re-run until all checks pass cleanly before proceeding
  6. Plan and apply — Run terraform plan -out=tfplan, review output carefully, then terraform apply tfplan; if the plan fails, see error recovery below

Error Recovery

Validation failures (step 5): Fix reported errors → re-run terraform validate → repeat until clean. For tflint warnings, address rule violations before proceeding.

Plan failures (step 6):

  • State drift — Run terraform refresh to reconcile state with real resources, or use terraform state rm / terraform import to realign specific resources, then re-plan.
  • Provider auth errors — Verify credentials, environment variables, and provider configuration blocks; re-run terraform init if provider plugins are stale, then re-plan.
  • Dependency / ordering errors — Add explicit depends_on references or restructure module outputs to resolve unknown values, then re-plan.

After any fix, return to step 5 to re-validate before re-running the plan.

Reference Guide

Load detailed guidance based on context:

TopicReferenceLoad When
Modulesreferences/module-patterns.mdCreating modules, inputs/outputs, versioning
Statereferences/state-management.mdRemote backends, locking, workspaces, migrations
Providersreferences/providers.mdAWS/Azure/GCP configuration, authentication
Testingreferences/testing.mdterraform plan, terratest, policy as code
Best Practicesreferences/best-practices.mdDRY patterns, naming, security, cost tracking

Constraints

MUST DO

  • Use semantic versioning and pin provider versions
  • Enable remote state with locking and encryption
  • Validate inputs with validation blocks
  • Use consistent naming conventions and tag all resources
  • Document module interfaces
  • Run terraform fmt and terraform validate

MUST NOT DO

  • Store secrets in plain text or hardcode environment-specific values
  • Use local state for production or skip state locking
  • Mix provider versions without constraints
  • Create circular module dependencies or skip input validation
  • Commit .terraform directories

Code Examples

Minimal Module Structure

main.tf

resource "aws_s3_bucket" "this" {
  bucket = var.bucket_name
  tags   = var.tags
}

variables.tf

variable "bucket_name" {
  description = "Name of the S3 bucket"
  type        = string

  validation {
    condition     = length(var.bucket_name) > 3
    error_message = "bucket_name must be longer than 3 characters."
  }
}

variable "tags" {
  description = "Tags to apply to all resources"
  type        = map(string)
  default     = {}
}

outputs.tf

output "bucket_id" {
  description = "ID of the created S3 bucket"
  value       = aws_s3_bucket.this.id
}

Remote Backend Configuration (S3 + DynamoDB)

terraform {
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "env/prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"
  }
}

Provider Version Pinning

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

Output Format

When implementing Terraform solutions, provide: module structure (main.tf, variables.tf, outputs.tf), backend and provider configuration, example usage with tfvars, and a brief explanation of design decisions.

Documentation

terraform-engineer — AI Skill | PluginBench