What this prompt does
This prompt casts the model as a senior test engineer who owns CI reliability and asks it to design an end-to-end suite that does not flake, returning working config and real tests rather than pseudocode. Four placeholders shape it: [tool] (Playwright or Cypress), [app] (the app under test), [ci] (the CI provider for sharding config), and [critical_flows] (the user journeys the example tests cover).
The structure works because a flaky E2E suite is worse than none — people stop trusting red builds and re-run until green. By requiring auth fixtures via storageState so tests skip the login UI, isolated data seeding and teardown, parallelism and sharding for [ci], a retry policy behind a quarantine tag rather than a blanket retry, visual-regression baselines, and reporting with traces and flaky-rate trends, the prompt builds reliability in from the start. The quarantine tag is what makes you fix flake instead of burying it. Scoping the example tests to [critical_flows] keeps the suite focused on journeys that actually matter, and naming [ci] ensures the sharding and reporting config targets your real pipeline rather than a generic one.
When to use it
- You are standing up an E2E suite for
[app]and want it reliable from day one. - Your existing suite flakes and the team has stopped trusting red builds.
- You need auth fixtures via
storageStateso tests skip the login UI per role. - You want sharding and parallelism configured for
[ci]with deterministic ordering. - You need a retry policy that tolerates real flake without hiding genuine failures.
- You want visual-regression checks and reporting with traces and flaky-rate trends.
Example output
Expect a full [tool] config plus three example tests covering [critical_flows] for [app]. The config includes auth fixtures using storageState (one helper per role), test-data seeding and teardown for isolated runs, parallelism and sharding for [ci] with deterministic ordering, a retry policy gated behind a quarantine tag, visual-regression baselines on key screens, and reporting that surfaces failures, traces, and a flaky-rate trend. The three tests demonstrate the patterns against your real flows.
Pro tips
- Put the retry policy behind a quarantine tag, not a blanket retry, so you fix flake instead of burying it under reruns.
- Use
storageStateauth fixtures so tests skip the login UI; logging in through the UI every test is a major flake source. - Keep
[critical_flows]to the journeys that actually matter (e.g. signup, add-to-cart, checkout) rather than trying to cover everything. - Make seeding and teardown isolate each run; shared mutable data is the classic cause of order-dependent flake.
- Match the sharding config to
[ci]and keep ordering deterministic so failures are reproducible across shards. - Commit visual-regression baselines deliberately and review diffs before updating them, so a real layout break is not silently accepted as the new baseline.
- Watch the flaky-rate trend in reporting; a rising rate is an early signal to quarantine and fix before the whole suite loses trust.
