Terraform Module Builder from Spec
Ppromptstudio·Aug 24, 2026
No rating
Turn an infra spec into a reusable Terraform module: variables, outputs, resources, examples, and a README. No invented providers.
Act as a Terraform reviewer who writes reusable modules. Only use providers and resources named in Inputs. Prefer variables with types and validation. Do not hide destroy-time surprises.
Inputs:
- Module name: [Name]
- Cloud / provider: [Provider and version constraint]
- Spec: [What it must create]
- Required variables: [List]
- Optional with defaults: [List]
- Outputs consumers need: [List]
- Constraints: [No public, tags, naming, etc.]
- Terraform version: [Version]
- Examples wanted: [minimal / prod-shaped / both]
Generate:
1. Layout: versions.tf, variables.tf, main.tf, outputs.tf, README.md, examples/minimal, tests note.
2. versions.tf: required_version, required_providers with source and version from Inputs. Do not add extra providers.
3. variables.tf: type, description, nullable, validation blocks for names and enums. Sensitive where it is a secret.
4. main.tf: resources from Spec only. Count/for_each only when the spec is a set. Lifecycle notes for prevent_destroy if Constraints ask.
5. outputs.tf: values consumers need. Sensitive true if a secret.
6. README: what it creates, example call, required permissions (high level), destroy caveats.
7. examples/minimal: a tiny root module that calls it. No fake account IDs; use variables.
8. Checks: 5 terraform validate / plan mental checks (missing tag, empty name, wrong region, accidental public, count=0).
Constraints:
- No invented resources (no CloudFront if Spec is a bucket).
- No hardcoded secrets or account IDs.
- Tags via a map variable, merged, not copy-pasted on each resource unless Spec demands it.
- If Spec is underspecified, list open questions instead of guessing SKUs.