---
name: playwright-e2e-test-planner
description: "Turns a described user flow into a Playwright test plan and runnable specs with stable locators, shared fixtures, and screenshots captured when a step fails. Use when a user flow in a web app needs Playwright tests with reliable locators, fixtures, and failure screenshots. Do not use for unit tests, load testing, or testing a mobile app. Related topics: coding, technical."
---

# Playwright E2E Test Planner

Turns a described user flow into a Playwright test plan and runnable specs with stable locators, shared fixtures, and screenshots captured when a step fails.

## When to use

Use this skill when a user flow in a web app needs Playwright tests with reliable locators, fixtures, and failure screenshots. Do not use it for unit tests, load testing, or testing a mobile app.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Split the flow into steps and write the assertion that proves each step worked.
3. Choose a locator for every element, preferring role and accessible name, then label or test id.
4. Move login and data setup into fixtures so each test starts clean and does not depend on another.
5. Write the specs using web-first assertions instead of fixed waits, with screenshots and traces kept on failure.
6. List what the suite does not cover and give the command to run it in CI.

## Inputs

- **The user flow** (longer free text)
- **App URL or route** (free text, e.g. "Where the flow starts")
- **Login needed** (choose one: Yes, No)
- **Test data setup** (longer free text)
- **Language** (choose one: TypeScript, JavaScript)
- **Browsers** (choose any: Chromium, Firefox, WebKit)

## Output

A table of planned tests with goals and assertions, then the spec and fixture code, then a short note on gaps and the CI command.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Playwright E2E Test Planner

Plan and write end-to-end tests for the flow below.

- The user flow: {{The user flow}}
- App URL or route: {{App URL or route}}
- Login needed: {{Login needed}}
- Test data setup: {{Test data setup}}
- Language: {{Language}}
- Browsers: {{Browsers}}

Break the flow into steps and decide what to assert after each one, such as a visible heading, a changed URL, or a saved record, since a step with no assertion proves nothing. Prefer locators by role and accessible name, then by label or test id, and avoid CSS chains and text that marketing may reword. Put login and data setup in fixtures so each test starts from a known state and stays independent of the others. Replace fixed sleeps with web-first assertions that wait for the condition. Configure screenshots and traces to be kept only on failure.

Return a table of tests (name, goal, assertions), then the spec file and fixture code. Finish with a short note on what is deliberately not covered and how to run the suite in CI.

## Pitfalls

- Chaining CSS selectors that break the first time the layout changes.
- Sharing one logged-in session and one record between tests, so a failure in one cascades into the rest.
- Using waitForTimeout to pass a flaky step, which makes the suite slow and still flaky.