- Home
- Skills
- Akin Ozer
- Cc Devops Skills
- Terraform Generator
terraform-generator_skill
- HCL
83
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill akin-ozer/cc-devops-skills --skill terraform-generator- SKILL.md28.1 KB
Overview
This skill generates production-ready Terraform (HCL) configurations that follow current best practices, conventions, and security patterns. It automatically checks for custom providers/modules, consults internal references, inserts required data sources and lifecycle protections, and drives a strict validate-and-fix loop until all syntax and security checks pass.
How this skill works
I analyze the requested infrastructure, detect required providers and modules, and consult provider/module documentation when third-party or custom components are present. I read the internal best-practices references, generate a standard file layout (main.tf, variables.tf, outputs.tf, versions.tf, backend.tf), add data sources for dynamic values, apply lifecycle protections on critical resources, and invoke an automated terraform validator to run fmt, init, validate and a security scan. I fix any validation or security failures and re-run validation until everything passes.
When to use it
- Creating new Terraform resources or full projects from scratch
- Scaffolding multi-file HCL layouts that follow organizational standards
- Adding modules or custom providers where documentation must be consulted
- Ensuring configurations include dynamic data sources and lifecycle protections
- Preparing code that must pass automated formatting, validation, and security scans
Best practices
- Always include data sources for region, account, AZs, and latest AMIs instead of hardcoding
- Use a consistent file layout: main.tf, variables.tf, outputs.tf, versions.tf, backend.tf
- Declare provider and Terraform version constraints in versions.tf and required_providers
- Add prevent_destroy lifecycle to KMS, databases, S3 buckets with data, and other critical resources
- Use locals for computed values and common_tags, and validation blocks on variables
- Run automated validation (fmt, init, validate) and security scan; fix failures and re-validate
Example use cases
- Generate an S3 bucket with versioning, lifecycle rules including abort_incomplete_multipart_upload, and prevent_destroy
- Scaffold a VPC using the terraform-aws-modules/vpc/aws module with version pinning and variable examples
- Create EC2 instances that reference a data aws_ami most_recent lookup and use locals for tags
- Produce RDS configuration with storage_encrypted = true and lifecycle.prevent_destroy = true
- Build multi-environment project layout and guidance for configuring remote state backends
FAQ
No. Sensitive values are declared as variables and left for terraform.tfvars or secret management; never hardcoded.
What happens if the validator reports a security check failure?
I fix the issue according to the check’s guidance (for example adding abort_incomplete_multipart_upload or tightening CIDR ranges) and re-run validation until all checks pass.