What this prompt does
This prompt frames the model as a senior platform engineer making an IaC tool decision -- Terraform vs Pulumi vs AWS CDK -- tight enough to act on, a decision rather than a feature table. You provide [team_shape], [cloud], [existing_tooling], and [hard_constraint], and it scores each tool, weighs the constraint, estimates onboarding, then leads with one clear recommendation, two tradeoffs, and a first-week plan.
The structure works because the IaC choice is sticky -- switching later is expensive, so the prompt forces a deliberate call. [team_shape] drives the language-familiarity and onboarding scoring (a TypeScript-heavy team leans differently than a Terraform-native one). [cloud] and [hard_constraint] (e.g. Vault secrets integration) can rule a tool in or out outright. By demanding the recommendation up front and two tradeoffs stated plainly, the prompt prevents the fence-sitting feature comparison that helps nobody decide, and the first-week plan turns the choice into something you can validate quickly.
When to use it
- You're picking an IaC tool and want a decision, not a feature matrix.
- Your team is split between a familiar language and Terraform's ecosystem maturity.
- You have a hard constraint (secrets, compliance) that could rule a tool in or out.
- You want onboarding time estimated for your specific team and existing tooling.
- You want the two tradeoffs of the chosen tool named plainly up front.
- You want a first-week plan to prove the choice before committing fully.
- You want a clear scoring of state management since it drives the long-term cost.
Example output
You get the recommendation first -- one tool, with the single reason that decided it -- then the scoring of all three against language familiarity, state management, and module ecosystem, the weighing against your hard constraint, an onboarding-time estimate, two tradeoffs you must accept, and a first-week migration plan naming what to build first to prove the choice. It reads as a decision memo you can circulate, not a comparison chart that leaves the call to you.
Pro tips
- Describe
[team_shape]honestly (10 engineers, mostly TypeScript) so the language-familiarity scoring reflects reality. - State the
[hard_constraint]as a true non-negotiable (must integrate with existing Vault secrets); it can rule a tool out outright. - List your real
[existing_tooling]so the onboarding estimate accounts for what you already run. - Force deliverable 5 -- every honest IaC choice has tradeoffs, and naming them upfront prevents resentment six months in.
- If the recommendation feels hedged, push back and make it commit to one tool with one deciding reason.
- Use the first-week plan as a cheap proof: build one real stack before betting the whole estate on the choice.
- Score state management explicitly; how each tool stores and locks state is often the real long-term differentiator.
