terraform-iac
Manages cloud infrastructure using Terraform (and OpenTofu). Use when the user wants to write Terraform configurations, provision cloud resources, manage state, create modules, set up multi-environment deployments, import existing infrastructure, debug plan/apply errors, migrate between providers, or implement IaC best practices. Trigger words: terraform, opentofu, infrastructure as code, IaC, tf, hcl, terraform module, terraform state, terraform plan, terraform apply, terraform import, cloud provisioning, AWS terraform, GCP terraform, Azure terraform.
What this skill does
# Terraform IaC
## Overview
Writes, reviews, and manages Terraform/OpenTofu configurations for cloud infrastructure. Covers resource definitions, modules, state management, multi-environment setups, CI/CD integration, drift detection, and migration from manual infrastructure to code. Supports AWS, GCP, Azure, and other providers.
## Instructions
### 1. Project Structure
Standard Terraform project layout:
```
infrastructure/
├── environments/
│ ├── dev/
│ │ ├── main.tf # Environment-specific config
│ │ ├── variables.tf # Environment variables
│ │ ├── terraform.tfvars # Variable values
│ │ └── backend.tf # State backend config
│ ├── staging/
│ └── production/
├── modules/
│ ├── networking/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ ├── compute/
│ ├── database/
│ └── monitoring/
├── shared/
│ └── providers.tf # Provider version constraints
└── README.md
```
For smaller projects, a flat structure is acceptable:
```
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tfvars
└── backend.tf
```
### 2. Writing Resources
Follow these conventions:
```hcl
# Use meaningful resource names that describe purpose
resource "aws_instance" "api_server" {
ami = var.ami_id
instance_type = var.instance_type
# Group related arguments
vpc_security_group_ids = [aws_security_group.api.id]
subnet_id = module.networking.private_subnet_ids[0]
# Tags on everything
tags = merge(var.common_tags, {
Name = "${var.project}-api-${var.environment}"
Role = "api-server"
})
# Lifecycle rules when needed
lifecycle {
create_before_destroy = true
ignore_changes = [ami] # AMI updated by CI/CD
}
}
```
**Naming conventions:**
- Resources: `snake_case`, descriptive (`web_server` not `ws1`)
- Variables: `snake_case`, prefixed by component when ambiguous (`db_instance_type`)
- Outputs: `snake_case`, prefixed by module name in root (`networking_vpc_id`)
- Files: group by logical component (`networking.tf`, `compute.tf`, `database.tf`)
### 3. Variables and Validation
Always define type, description, and validation:
```hcl
variable "environment" {
type = string
description = "Deployment environment (dev, staging, production)"
validation {
condition = contains(["dev", "staging", "production"], var.environment)
error_message = "Environment must be dev, staging, or production."
}
}
variable "instance_type" {
type = string
description = "EC2 instance type for the API server"
default = "t3.medium"
validation {
condition = can(regex("^t3\\.", var.instance_type))
error_message = "Only t3 instance types are allowed for cost control."
}
}
# Use locals for computed values
locals {
name_prefix = "${var.project}-${var.environment}"
is_prod = var.environment == "production"
common_tags = {
Project = var.project
Environment = var.environment
ManagedBy = "terraform"
Team = var.team
}
}
```
### 4. Modules
Write reusable modules for repeated patterns:
```hcl
# modules/ecs-service/variables.tf
variable "name" {
type = string
description = "Service name"
}
variable "container_image" {
type = string
description = "Docker image URI"
}
variable "cpu" {
type = number
default = 256
}
variable "memory" {
type = number
default = 512
}
# modules/ecs-service/main.tf
resource "aws_ecs_task_definition" "this" {
family = var.name
requires_compatibilities = ["FARGATE"]
network_mode = "awsvpc"
cpu = var.cpu
memory = var.memory
container_definitions = jsonencode([{
name = var.name
image = var.container_image
essential = true
portMappings = [{
containerPort = var.container_port
protocol = "tcp"
}]
logConfiguration = {
logDriver = "awslogs"
options = {
"awslogs-group" = aws_cloudwatch_log_group.this.name
"awslogs-region" = data.aws_region.current.name
"awslogs-stream-prefix" = var.name
}
}
}])
}
# Usage in root
module "api" {
source = "./modules/ecs-service"
name = "api"
container_image = "123456.dkr.ecr.us-east-1.amazonaws.com/api:latest"
cpu = 512
memory = 1024
}
```
**Module guidelines:**
- One module per logical component (networking, compute, database, monitoring)
- Expose only necessary variables — sensible defaults for everything else
- Always define outputs for values other modules need
- Pin module source versions: `source = "git::https://...?ref=v1.2.0"`
### 5. State Management
**Remote state (required for teams):**
```hcl
# AWS S3 backend
terraform {
backend "s3" {
bucket = "company-terraform-state"
key = "env/production/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
```
**State operations:**
```bash
# List all resources in state
terraform state list
# Show details of a resource
terraform state show aws_instance.api_server
# Move a resource (rename without recreate)
terraform state mv aws_instance.old_name aws_instance.new_name
# Import existing infrastructure
terraform import aws_instance.api_server i-0abc123def456
# Remove from state (without destroying)
terraform state rm aws_instance.temp_server
```
**State safety:**
- Always use remote state with locking (DynamoDB for S3, GCS native for GCP)
- Never edit state files manually
- Use `terraform plan` before every `apply`
- Enable state versioning on the storage bucket
### 6. Multi-Environment Strategy
**Option A: Workspaces** (simple, same config):
```bash
terraform workspace new staging
terraform workspace select production
terraform apply -var-file="production.tfvars"
```
**Option B: Directory per environment** (recommended, different configs):
```
environments/dev/ → smaller instances, single AZ
environments/staging/ → mirrors prod at smaller scale
environments/prod/ → full HA, multi-AZ, larger instances
```
Each environment references shared modules with different variable values.
**Option C: Terragrunt** (DRY multi-environment):
```hcl
# terragrunt.hcl
terraform {
source = "../../modules//networking"
}
inputs = {
environment = "production"
vpc_cidr = "10.0.0.0/16"
az_count = 3
}
```
### 7. Import Existing Infrastructure
For brownfield environments:
```bash
# 1. Write the resource block first
# 2. Import the real resource into state
terraform import aws_vpc.main vpc-0abc123
# 3. Run plan to see drift
terraform plan
# 4. Adjust config until plan shows no changes
```
Terraform 1.5+ supports import blocks:
```hcl
import {
to = aws_instance.api_server
id = "i-0abc123def456"
}
```
Generate config automatically:
```bash
terraform plan -generate-config-out=generated.tf
```
### 8. CI/CD Integration
```yaml
# GitHub Actions
- name: Terraform Plan
run: |
terraform init
terraform plan -out=tfplan -no-color
- name: Terraform Apply
if: github.ref == 'refs/heads/main'
run: terraform apply -auto-approve tfplan
```
**Best practices for CI/CD:**
- Always run `plan` on PRs, `apply` only on merge to main
- Use `-out=tfplan` to ensure apply matches the reviewed plan
- Store plan artifacts for audit trails
- Use OIDC for cloud credentials (no static keys in CI)
- Add cost estimation with Infracost: `infracost breakdown --path .`
### 9. Security
- Never commit `.tfvars` files with secrets — use environment variables or a secrets manager
- Use `sensitive = true` on variables containing secrets
- Enable encryption on state backends
- Use IAM roles with least privilege for Terraform execution
- Scan configs with `tfsec`, `checkov`, or `trivy config`
- Pin provider versions: `required_providers { aws = { version = "~> 5.0" } }`
## Examples
###Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.