What this prompt does
This prompt makes the AI reason through a multi-environment Terraform strategy as a deliberate engineering decision rather than defaulting to whatever it saw most online. You provide [tool_choice] and [project_description], list your [environments] and their [environment_differences], and give it the constraints that actually drive the call: [team_size], [complexity_level], and [budget_constraints]. It then compares Terraform workspaces, Terragrunt, directory-per-environment, and Terraform Cloud, and recommends one for your situation.
The structure works because the right answer depends entirely on context. A three-person team with a tight budget should not be told to buy Enterprise. By forcing the model to lay out the directory structure showing where [config_elements] live, apply a [dry_strategy] with before/after examples for [duplication_example], design a promotion workflow from [first_env] to [last_env] with [promotion_gates], and handle [env_specific_resources] plus [secret_management], you get an opinionated, complete blueprint instead of a feature comparison you still have to decide from. The [project_description] anchors all of this to a real stack, so the module references and backend layout match what you actually deploy.
When to use it
- You are starting a new IaC repo and have not committed to workspaces vs Terragrunt yet
- You are drowning in copy-pasted config across dev, staging, and production
- You need a defensible recommendation to show a team before standardizing
- You want a promotion workflow that defines
[promotion_gates]at each stage - You have resources like WAF or VPN that exist only in some environments
- You need per-environment secret isolation so
[first_env]credentials cannot reach[last_env] - You want environment-specific sizing without forking module code
Example output
Expect a comparison section weighing the four approaches against your [team_size] and [complexity_level], a single recommendation with rationale, and an annotated directory tree showing exactly where [config_elements] go. You then get before/after code snippets demonstrating the [dry_strategy] on [duplication_example], a promotion flow diagram, a [variable_strategy] for sizing differences like [sizing_examples], and a complete working file set for a [example_resource] across every environment. The output also explains how [env_specific_resources] such as WAF or VPN are conditionally created only where they belong, so you are not littering production-only resources across dev.
Pro tips
- Be honest about
[budget_constraints]— saying you want to avoid the Enterprise tier steers it toward open-source Terragrunt patterns instead of paid features - Make
[environment_differences]specific; "dev: single AZ, prod: multi-AZ full HA" produces a far better sizing strategy than "they differ" - Use
[duplication_example]to point at your worst real duplication so the DRY refactor is relevant - Set
[promotion_gates]to your actual approval reality, whether that is a CAB for production or just a team-lead review - Pin
[example_resource]to something you genuinely run so the complete file set is copy-ready - Keep
[variable_strategy]consistent across environments so a new engineer can predict where any value is set - If the recommendation surprises you, ask it to defend the rejected options — that pressure-tests the call before you commit a repo to it
