What this prompt does
This prompt designs a complete test environment and data management strategy for a [team_size]-person team building a [app_type], anchored to the [pain_points] you list. It produces a tiered plan — local, CI, staging, pre-prod — with a clear purpose and data policy for each tier, then layers on a database strategy ([db_strategy]), test data generation via [seed_approach], masking of [sensitive_data] in production snapshots, on-demand provisioning triggered by [provision_trigger], cleanup policies, drift monitoring, and cost controls.
The structure works because environment problems are rarely one issue — they are a tangle of stale data, shared staging, and slow setup. By forcing a per-tier data policy and an explicit [idle_timeout] auto-shutdown plus a [setup_time] self-service target, the output addresses both the reliability side (flaky tests, leaked PII) and the cost side (idle environments burning money). Naming your real [pain_points] keeps the recommendations targeted rather than generic best-practice boilerplate.
When to use it
- When flaky tests trace back to a shared, stale staging environment
- When onboarding takes hours because spinning up a working environment is manual
- Before adopting ephemeral per-PR environments and you need a data policy first
- When you want to use production snapshots safely and must mask
[sensitive_data] - When cloud spend on idle test environments is climbing and needs guardrails
- When multiple teams keep stepping on each other's shared test data
Example output
Expect a structured strategy document: a per-tier table of purpose and data policy across local, CI, staging, and pre-prod, a database approach for each tier reflecting [db_strategy], a seeding and masking plan, a provisioning workflow triggered by [provision_trigger], cleanup and cost rules including the [idle_timeout] auto-shutdown, plus implementation priorities. The masking section enumerates how each field in [sensitive_data] is anonymized when production snapshots are reused, and the self-service workflow targets your [setup_time] goal. It typically includes an architecture diagram description and an ordered rollout list rather than a single block of prose, so you can hand it to the team and start executing.
Pro tips
- Be honest and specific in
[pain_points]— this variable steers the whole plan, so list the real failures (shared staging, slow setup) rather than aspirations - Match
[db_strategy]to your CI budget; ephemeral per-PR databases are great but verify your runners can spin them up within your[setup_time]target - Enumerate every field in
[sensitive_data]you must mask — anything you forget is a real leak risk when using production snapshots - Use deterministic seeds in
[seed_approach]so failing tests reproduce; non-deterministic data is a hidden source of flakiness - Set
[idle_timeout]aggressively for short-lived per-PR environments and more leniently for shared ones to balance cost and convenience - Tie
[provision_trigger]to your actual git workflow so environments appear exactly when reviewers need them
