Terraform and Infrastructure as Code optimization guidelines from Terramate. This skill should be used when writing, reviewing, or refactoring Terraform/OpenTofu code to ensure optimal patterns for security, maintainability, and reliability. Triggers on tasks involving Terraform modules, infrastructure provisioning, state management, or IaC optimization.
52
56%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/terraform-best-practices/SKILL.mdComprehensive optimization guide for Terraform and Infrastructure as Code, maintained by Terramate. Contains 37 rules across 10 categories, prioritized by impact to guide automated refactoring and code generation.
Reference these guidelines when:
| Priority | Category | Impact | Prefix |
|---|---|---|---|
| 1 | Organization & Workflow | CRITICAL | org- |
| 2 | State Management | CRITICAL | state- |
| 3 | Security Best Practices | CRITICAL | security- |
| 4 | Module Design | HIGH | module- |
| 5 | Resource Organization | MEDIUM-HIGH | resource- |
| 6 | Variable & Output Patterns | MEDIUM | variable-, output- |
| 7 | Language Best Practices | MEDIUM | language- |
| 8 | Provider Configuration | MEDIUM | provider- |
| 9 | Performance Optimization | LOW-MEDIUM | perf- |
| 10 | Testing & Validation | LOW | test- |
org-version-control - All Terraform code in version controlorg-workspaces - One workspace per environment per configurationorg-access-control - Control who can change what infrastructureorg-change-workflow - Formal process for infrastructure changesorg-audit-logging - Track all infrastructure changesstate-remote-backend - Always use remote state backendsstate-locking - Enable state locking to prevent corruptionstate-import - Import existing infrastructure into Terraformsecurity-no-hardcoded-secrets - Never hardcode secrets in codesecurity-credentials - Use proper credential management (OIDC, Vault, IAM roles)security-iam-least-privilege - Follow least privilege principlemodule-single-responsibility - One module per logical componentmodule-naming - Use consistent naming conventions (terraform--)module-versioning - Version all module referencesmodule-composition - Compose modules like building blocksmodule-registry - Use existing community/shared modulesresource-naming - Use consistent naming conventionsresource-tagging - Tag all resources for cost trackingresource-lifecycle - Use lifecycle blocks (prevent_destroy, ignore_changes)resource-count-vs-foreach - Prefer for_each over countresource-immutable - Prefer immutable infrastructure patternsvariable-types - Use specific types, positive naming, nullablevariable-validation - Add validation rules for early error detectionvariable-sensitive - Mark secrets as sensitive, no defaultsvariable-descriptions - Document all variables with descriptionsoutput-descriptions - Document all outputs with descriptionsoutput-no-secrets - Never output secrets directlylanguage-no-heredoc-json - Use jsonencode/yamlencode, not HEREDOClanguage-locals - Use locals to name complex expressionslanguage-linting - Run terraform fmt and tflintlanguage-data-sources - Use data sources instead of hardcodinglanguage-dynamic-blocks - Use dynamic blocks for DRY codeprovider-version-constraints - Pin provider versionsperf-parallelism - Tune parallelism for large deploymentsperf-debug - Enable debug logging for troubleshootingtest-strategies - Testing pyramid (validate, lint, plan, integration)test-policy-as-code - Implement policy checks (OPA, Checkov, tfsec)Read individual rule files for detailed explanations and code examples:
rules/state-remote-backend.md
rules/security-no-hardcoded-secrets.md
rules/module-versioning.mdEach rule file contains:
For the complete guide with all rules expanded: AGENTS.md
fb28900
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.