What this prompt does
This prompt designs a reusable Terraform module for [module_purpose] on [cloud_provider], meant to be consumed by [consumer_count] teams across [environment_count] environments. It lays out the standard file structure (main.tf, variables.tf, outputs.tf, versions.tf with required_providers, and locals.tf) and defines input variables for [key_variables] using object types, optional() defaults, and validation blocks enforcing [validation_rules].
It establishes a naming convention built from [naming_components] so every resource is named consistently, tags everything with [required_tags] via a merge of default and user-supplied tags, and uses count or for_each for [conditional_resources] so consumers can opt in or out of costly pieces. Outputs expose [module_outputs] including both IDs and ARNs or names for maximum consumer flexibility, marking secret outputs sensitive=true. Finally it asks for a comprehensive README with usage examples for [usage_scenarios], input and output reference tables, a [diagram_format] architecture diagram, and pre-commit hooks running terraform fmt, validate, tflint, and checkov or tfsec for security scanning. The aim is a module that survives reuse because its inputs are validated, its outputs are documented, and its defaults are sane.
When to use it
- You're publishing a Terraform module multiple teams will reuse
- You want strict variable validation so misconfiguration fails at plan time
- You need consistent resource naming and tagging across environments
- You want optional components (NAT gateways, VPN) that consumers can toggle
- You need a README good enough that a teammate uses it without asking you
- You want security and lint scanning wired in via pre-commit hooks
- You're standardizing a module library and want one consistent structure across them
Example output
The AI returns the five-file module skeleton, typed variables with validation blocks for [validation_rules], a locals-based naming scheme from [naming_components], a tag-merge pattern, conditional resource definitions using for_each or count, an outputs file with sensitive flags, and a README with usage examples and a [diagram_format] diagram. Expect a pre-commit config too, with the output structured per numbered concern so you can lift the validation or tagging patterns into existing modules.
Pro tips
- Write validation blocks for every rule in
[validation_rules](CIDR size, AZ count) so bad input fails at plan, not apply - Use
optional()in object-typed[key_variables]so consumers only set what they need - Drive
[conditional_resources]with a boolean variable per component so dev can skip the costly NAT gateway - Output both IDs and ARNs/names in
[module_outputs]to maximize what downstream modules can reference - Mark any secret output
sensitive=trueso it doesn't leak into plan logs - Pin provider versions in versions.tf so a consumer's provider upgrade can't silently change behavior
- Keep
[required_tags]in a merged default-plus-override map so consumers can add tags without losing the mandatory ones
