Terraform Style Guide

HashiCorpOfficialPublished by HashiCorp

Skill
Guidelines
Cloud and DevOps
MPL-2.0
No issues found

From the author

Generate Terraform HCL code following HashiCorp's official style conventions and best practices. Use when writing, reviewing, or generating Terraform configurations.

— the description by HashiCorp

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured reference for Terraform development, covering file organization, naming conventions, formatting, and best practices for variables and outputs. It serves as a manual for ensuring consistency across Terraform configurations, offering guidance on dependency management, provider configuration, and version pinning. The guide includes a code review checklist to help developers verify their configurations before deployment.

What it does

Defines standard file structures for Terraform projects
Provides formatting rules for indentation and block organization
Establishes naming conventions for resources and variables
Outlines requirements for variable and output documentation
Offers guidance on version pinning and provider configuration
Includes a checklist for reviewing Terraform code quality

When to use it

When writing new Terraform infrastructure code
When refactoring existing Terraform configurations
During the code review process for infrastructure changes
When establishing team standards for Terraform development

Advantages

Promotes consistent and readable infrastructure code
Reduces technical debt through standardized file organization
Ensures all variables and outputs are properly documented
Helps prevent common configuration errors through best practices

Usage examples

“How should I structure my Terraform files for a new project?”: The skill provides a standard file structure including terraform.tf, providers.tf, main.tf, variables.tf, outputs.tf, and locals.tf.
“What are the naming conventions for Terraform resources?”: The guide specifies using lowercase with underscores, descriptive nouns, and singular resource names.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/hashicorp/terraform-style-guide/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip terraform-style-guide.zip -d .agents/skills

Documentation by HashiCorp

Terraform Style Guide

Generate and maintain Terraform code following HashiCorp's official style conventions and best practices.

Reference: HashiCorp Terraform Style Guide

Code Generation Strategy

When generating Terraform code:

Start with provider configuration and version constraints
Create data sources before dependent resources
Build resources in dependency order
Add outputs for key resource attributes
Use variables for all configurable values

File Organization

File	Purpose
`terraform.tf`	Terraform and provider version requirements
`providers.tf`	Provider configurations
`main.tf`	Primary resources and data sources
`variables.tf`	Input variable declarations (alphabetical)
`outputs.tf`	Output value declarations (alphabetical)
`locals.tf`	Local value declarations

Example Structure

# terraform.tf
terraform {
  required_version = ">= 1.14"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# variables.tf
variable "environment" {
  description = "Target deployment environment"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

# locals.tf
locals {
  common_tags = {
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

# main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true

  tags = merge(local.common_tags, {
    Name = "${var.project_name}-${var.environment}-vpc"
  })
}

# outputs.tf
output "vpc_id" {
  description = "ID of the created VPC"
  value       = aws_vpc.main.id
}

Code Formatting

Indentation and Alignment

Use two spaces per nesting level (no tabs)
Align equals signs for consecutive arguments

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  subnet_id     = "subnet-12345678"

  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

Block Organization

Arguments precede blocks, with meta-arguments first:

resource "aws_instance" "example" {
  # Meta-arguments
  count = 3

  # Arguments
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  # Blocks
  root_block_device {
    volume_size = 20
  }

  # Lifecycle last
  lifecycle {
    create_before_destroy = true
  }
}

Naming Conventions

Use lowercase with underscores for all names
Use descriptive nouns excluding the resource type
Be specific and meaningful
Resource names must be singular, not plural
Default to main for resources where a specific descriptive name is redundant or unavailable, provided only one instance exists

# Bad
resource "aws_instance" "webAPI-aws-instance" {}
resource "aws_instance" "web_apis" {}
variable "name" {}

# Good
resource "aws_instance" "web_api" {}
resource "aws_vpc" "main" {}
variable "application_name" {}

Variables

Every variable must include type and description:

variable "instance_type" {
  description = "EC2 instance type for the web server"
  type        = string
  default     = "t2.micro"

  validation {
    condition     = contains(["t2.micro", "t2.small", "t2.medium"], var.instance_type)
    error_message = "Instance type must be t2.micro, t2.small, or t2.medium."
  }
}

variable "database_password" {
  description = "Password for the database admin user"
  type        = string
  sensitive   = true
}

Outputs

Every output must include description:

output "instance_id" {
  description = "ID of the EC2 instance"
  value       = aws_instance.web.id
}

output "database_password" {
  description = "Database administrator password"
  value       = aws_db_instance.main.password
  sensitive   = true
}

Dynamic Resource Creation

Prefer for_each over count

# Bad - count for multiple resources
resource "aws_instance" "web" {
  count = var.instance_count
  tags  = { Name = "web-${count.index}" }
}

# Good - for_each with named instances
variable "instance_names" {
  type    = set(string)
  default = ["web-1", "web-2", "web-3"]
}

resource "aws_instance" "web" {
  for_each = var.instance_names
  tags     = { Name = each.key }
}

count for Conditional Creation

resource "aws_cloudwatch_metric_alarm" "cpu" {
  count = var.enable_monitoring ? 1 : 0

  alarm_name = "high-cpu-usage"
  threshold  = 80
}

Security Best Practices

Refer to SECURITY.md. It includes guidance on encrypting resources, preventing sensitive data in state, and secure configurations.

Version Pinning

terraform {
  required_version = ">= 1.14"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

Use the latest major version of each provider and the latest minor version of Terraform, unless otherwise constrained by a dependency lock file or by other modules used by the configuration.

Version constraint operators:

= 1.0.0 - Exact version
>= 1.0.0 - Greater than or equal
~> 1.0 - Allow rightmost component to increment
>= 1.0, < 2.0 - Version range

Provider Configuration

provider "aws" {
  region = "us-west-2"

  default_tags {
    tags = {
      ManagedBy = "Terraform"
      Project   = var.project_name
    }
  }
}

# Aliased provider for multi-region
provider "aws" {
  alias  = "east"
  region = "us-east-1"
}

Version Control

Never commit:

terraform.tfstate, terraform.tfstate.backup
.terraform/ directory
*.tfplan
.tfvars files with sensitive data

Always commit:

All .tf configuration files
.terraform.lock.hcl (dependency lock file)

Validation Tools

Run before committing:

terraform fmt -recursive
terraform validate

Additional tools:

tflint - Linting and best practices
checkov / tfsec - Security scanning

Code Review Checklist

[ ] Code formatted with terraform fmt
[ ] Configuration validated with terraform validate
[ ] Files organized according to standard structure
[ ] All variables have type and description
[ ] All outputs have descriptions
[ ] Resource names use descriptive nouns with underscores
[ ] Version constraints pinned explicitly
[ ] Sensitive values marked with sensitive = true
[ ] No hardcoded credentials or secrets
[ ] Security best practices applied

Based on: HashiCorp Terraform Style Guide

Files

ATTRIBUTION.mdAdded by AutoGineer910 B
LICENSELicence file added by AutoGineer16.3 KiB
SECURITY.md4.8 KiB
SKILL.md6.8 KiB

SKILL.md

Terraform Style Guide

Generate and maintain Terraform code following HashiCorp's official style conventions and best practices.

Reference: HashiCorp Terraform Style Guide

Code Generation Strategy

When generating Terraform code:

Start with provider configuration and version constraints
Create data sources before dependent resources
Build resources in dependency order
Add outputs for key resource attributes
Use variables for all configurable values

File Organization

File	Purpose
`terraform.tf`	Terraform and provider version requirements
`providers.tf`	Provider configurations
`main.tf`	Primary resources and data sources
`variables.tf`	Input variable declarations (alphabetical)
`outputs.tf`	Output value declarations (alphabetical)
`locals.tf`	Local value declarations

Example Structure

# terraform.tf
terraform {
  required_version = ">= 1.14"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# variables.tf
variable "environment" {
  description = "Target deployment environment"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

# locals.tf
locals {
  common_tags = {
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

# main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true

  tags = merge(local.common_tags, {
    Name = "${var.project_name}-${var.environment}-vpc"
  })
}

# outputs.tf
output "vpc_id" {
  description = "ID of the created VPC"
  value       = aws_vpc.main.id
}

Code Formatting

Indentation and Alignment

Use two spaces per nesting level (no tabs)
Align equals signs for consecutive arguments

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  subnet_id     = "subnet-12345678"

  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

Block Organization

Arguments precede blocks, with meta-arguments first:

resource "aws_instance" "example" {
  # Meta-arguments
  count = 3

  # Arguments
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  # Blocks
  root_block_device {
    volume_size = 20
  }

  # Lifecycle last
  lifecycle {
    create_before_destroy = true
  }
}

Naming Conventions

Use lowercase with underscores for all names
Use descriptive nouns excluding the resource type
Be specific and meaningful
Resource names must be singular, not plural
Default to main for resources where a specific descriptive name is redundant or unavailable, provided only one instance exists

# Bad
resource "aws_instance" "webAPI-aws-instance" {}
resource "aws_instance" "web_apis" {}
variable "name" {}

# Good
resource "aws_instance" "web_api" {}
resource "aws_vpc" "main" {}
variable "application_name" {}

Variables

Every variable must include type and description:

variable "instance_type" {
  description = "EC2 instance type for the web server"
  type        = string
  default     = "t2.micro"

  validation {
    condition     = contains(["t2.micro", "t2.small", "t2.medium"], var.instance_type)
    error_message = "Instance type must be t2.micro, t2.small, or t2.medium."
  }
}

variable "database_password" {
  description = "Password for the database admin user"
  type        = string
  sensitive   = true
}

Outputs

Every output must include description:

output "instance_id" {
  description = "ID of the EC2 instance"
  value       = aws_instance.web.id
}

output "database_password" {
  description = "Database administrator password"
  value       = aws_db_instance.main.password
  sensitive   = true
}

Dynamic Resource Creation

Prefer for_each over count

# Bad - count for multiple resources
resource "aws_instance" "web" {
  count = var.instance_count
  tags  = { Name = "web-${count.index}" }
}

# Good - for_each with named instances
variable "instance_names" {
  type    = set(string)
  default = ["web-1", "web-2", "web-3"]
}

resource "aws_instance" "web" {
  for_each = var.instance_names
  tags     = { Name = each.key }
}

count for Conditional Creation

resource "aws_cloudwatch_metric_alarm" "cpu" {
  count = var.enable_monitoring ? 1 : 0

  alarm_name = "high-cpu-usage"
  threshold  = 80
}

Security Best Practices

Refer to SECURITY.md. It includes guidance on encrypting resources, preventing sensitive data in state, and secure configurations.

Version Pinning

terraform {
  required_version = ">= 1.14"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

Use the latest major version of each provider and the latest minor version of Terraform, unless otherwise constrained by a dependency lock file or by other modules used by the configuration.

Version constraint operators:

= 1.0.0 - Exact version
>= 1.0.0 - Greater than or equal
~> 1.0 - Allow rightmost component to increment
>= 1.0, < 2.0 - Version range

Provider Configuration

provider "aws" {
  region = "us-west-2"

  default_tags {
    tags = {
      ManagedBy = "Terraform"
      Project   = var.project_name
    }
  }
}

# Aliased provider for multi-region
provider "aws" {
  alias  = "east"
  region = "us-east-1"
}

Version Control

Never commit:

terraform.tfstate, terraform.tfstate.backup
.terraform/ directory
*.tfplan
.tfvars files with sensitive data

Always commit:

All .tf configuration files
.terraform.lock.hcl (dependency lock file)

Validation Tools

Run before committing:

terraform fmt -recursive
terraform validate

Additional tools:

tflint - Linting and best practices
checkov / tfsec - Security scanning

Code Review Checklist

[ ] Code formatted with terraform fmt
[ ] Configuration validated with terraform validate
[ ] Files organized according to standard structure
[ ] All variables have type and description
[ ] All outputs have descriptions
[ ] Resource names use descriptive nouns with underscores
[ ] Version constraints pinned explicitly
[ ] Sensitive values marked with sensitive = true
[ ] No hardcoded credentials or secrets
[ ] Security best practices applied

Based on: HashiCorp Terraform Style Guide

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs a command-line tool

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

HashiCorp

Publisher

HashiCorp (Official)

Source

hashicorp/agent-skills · plugins/terraform/skills/terraform-style-guide · commit 5e30fa5

Licence

Mozilla Public License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by HashiCorp.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download terraform-style-guide.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by HashiCorp

Terraform Style Guide

Code Generation Strategy

File Organization

Example Structure

Code Formatting

Indentation and Alignment

Block Organization

Naming Conventions

Variables

Outputs

Dynamic Resource Creation

Prefer for_each over count

count for Conditional Creation

Security Best Practices

Version Pinning

Provider Configuration

Version Control

Validation Tools

Code Review Checklist

Files

SKILL.md

Terraform Style Guide

Code Generation Strategy

File Organization

Example Structure

Code Formatting

Indentation and Alignment

Block Organization

Naming Conventions

Variables

Outputs

Dynamic Resource Creation

Prefer for_each over count

count for Conditional Creation

Security Best Practices

Version Pinning

Provider Configuration

Version Control

Validation Tools

Code Review Checklist

Requirements and compatibility

Security

Attribution and licence

Related skills

Deployment Strategies Terraform Specialist

Terraform Module Library

Cloud Infrastructure Terraform Specialist

Cicd Automation Terraform Specialist

Terraform Azure Planning

Terratest Module Testing

Download ZIP