What this prompt does
This prompt builds cloud infrastructure with Pulumi and TypeScript for [infrastructure_purpose] on [cloud_provider], serving [application_type] with [availability_requirement] availability. It lays out the project structure (Pulumi.yaml, per-stack config for [stack_names], index.ts as entry point, and a components directory) and a typed ComponentResource class for [component_name] that encapsulates [component_resources] with proper parent/child relationships and exposes outputs as pulumi.Output<T>.
The distinguishing point is using real language features Terraform's HCL lacks: map/filter over [dynamic_resources] to generate resources programmatically, async/await for [async_operations], and genuine if/else for [conditional_logic] instead of count hacks. It uses typed pulumi.Config getters, secret values for [secret_configs], typed StackReference for [cross_stack_outputs], custom providers for [custom_provider_needs] where native resources fall short, and unit tests via @pulumi/pulumi/testing that mock the cloud provider to verify [test_scenarios], run with [test_framework]. The payoff is infrastructure expressed as ordinary typed code, where loops, conditionals, and abstractions read the way the rest of your application does.
When to use it
- You need loops or conditionals that HCL makes awkward (generating per-service resources)
- You want typed, reusable ComponentResources with real interfaces
- You need async lookups (latest AMI, resource-by-tag) during provisioning
- You want true if/else conditional infrastructure instead of count tricks
- You need to share outputs between stacks with type safety
- You want unit tests that mock the cloud and assert resource properties
- Your team already knows TypeScript and prefers it over learning HCL idioms
- You want secrets typed and encrypted in config rather than passed around as plain strings
Example output
The AI returns the Pulumi project layout, a ComponentResource class for [component_name] exposing pulumi.Output<T> outputs, map/filter loops generating [dynamic_resources], async/await examples for [async_operations], typed Config usage with secrets, StackReference code for [cross_stack_outputs], and [test_framework] unit tests mocking the provider for [test_scenarios]. Expect TypeScript code blocks grouped by the seven concerns, with typed interfaces so misuse is caught at compile time.
Pro tips
- Model
[dynamic_resources]as a typed config array and map over it, so adding a service is a one-line data change - Use async/await only where you genuinely need a lookup (
[async_operations]); overusing it complicates the resource graph - Express
[conditional_logic]with real if/else and return different resources, which reads far cleaner than Terraform count hacks - Mark
[secret_configs]as secrets inpulumi.Configso they're encrypted in state and config files - Type your StackReference outputs for
[cross_stack_outputs]so a renamed output fails at compile time, not runtime - Set explicit parent relationships in your ComponentResource so the resource graph and previews stay readable
- Reach for a custom provider in
[custom_provider_needs]only when a native resource genuinely can't express what you need - Keep
[test_scenarios]focused on security-relevant assertions (no 0.0.0.0/0, encryption on) where mocked tests add the most value
