What this prompt does
This prompt scaffolds a complete end-to-end testing framework rather than a single test. You specify [e2e_tool], the [app_type], and the [framework] it is built with, and the AI produces a page-object-model project structure: a base page class with shared helpers, fixtures and factory data, [test_count] example tests covering your [critical_flows], auth helpers for [auth_method], parallel runs across [parallel_count] workers, GitHub Actions CI, and HTML reporting.
The structure works because it front-loads the architecture decisions that usually get skipped. By demanding the page object pattern, a base class, and fixtures up front, the prompt produces a layout the team can extend instead of a pile of brittle scripts. The variables for [critical_flows] and [auth_method] make the examples concrete to your app, and the CI plus parallel-worker requirements mean the output is wired into a pipeline, not just runnable locally.
When to use it
- You are launching a
[app_type]and want E2E coverage before the first incident, not after. - You need a page-object structure that scales as the app grows.
- You want login, CRUD, and other
[critical_flows]protected against silent breakage. - You are standing up GitHub Actions CI for browser tests with caching.
- You need parallel execution tuned to
[parallel_count]workers. - You want screenshots and video captured automatically on failure.
Example output
You get a full project skeleton: a pages/ directory of page objects, a base page class, fixtures, [test_count] example specs for your [critical_flows], auth helper commands, a [e2e_tool] config with [parallel_count] workers, a GitHub Actions workflow with caching, plus package.json scripts and a team README. Failure artifacts (screenshots, video) are configured out of the box.
Pro tips
- List your real
[critical_flows]precisely — vague flows produce vague tests; name the exact screens and actions. - Match
[auth_method]to how your app actually logs in, since auth helpers are reused by nearly every test. - Keep
[parallel_count]aligned to your CI runner's cores; over-provisioning workers causes flaky, resource-starved runs. - Treat the generated specs as scaffolding — selectors will need adjusting to your real DOM.
- Set
[environments]to match your deploy stages so config switching works locally and in CI. - Start with a small
[test_count]to validate the structure, then expand once the base class and fixtures are stable.
