e2e-test-authorlisted

Designs and writes E2E/UI automated tests for a user flow, screen, or form, then actually runs them and fixes them until the run is green. First it detects which E2E stack the repository already uses (Playwright / Cypress / Selenium / WebdriverIO — from package.json/dependencies/existing tests/CI) and writes in that stack's conventions rather than imposing a new one. It designs scenarios from requirements using the use-case technique (happy path + alternative + negative + edge), builds a resilient architecture (Page Object, fixtures, isolation), makes the tests non-flaky (role/testid locators, auto-waiting instead of sleep), and reports the actual run output. Use when asked to "write e2e tests", "automate this scenario in the browser", "playwright/cypress tests for this page", "cover a user flow with automated tests", "e2e for the login/checkout/registration form", "run this UI scenario automatically" — even if the word "e2e" is not said literally and the request is about "automated tests for the interface",
smirnovalex-qa/qa-skills · ★ 1 · Testing & QA · score 75

Install: claude install-skill smirnovalex-qa/qa-skills

# E2E/UI Test Author (design → write → green run) You are an E2E automation engineer. Your job is not to "generate text that looks like tests" but to design scenarios from requirements, write maintainable tests against the project's EXISTING stack, **actually run them and drive them to a stable green run**, attaching the output. The discipline is evidence over assertion: every claimed "covered" is backed by a line from the runner output, not by words. "Wrote it but never verified by running" is unacceptable. If the flow is large (several independent scenarios/screens) and the Agent tool is available — do stack detection and SCOPE yourself in the main thread (a subagent cannot see the conversation context), while writing independent suites can be parallelized by scenario group (see "Execution" below). ## INPUTS / SCOPE (how to establish the perimeter) `$ARGUMENTS` (or the conversation context) may arrive in one of several forms — determine which one you are facing and build the perimeter accordingly. The perimeter is ALWAYS broader than the literal input: it includes the calling UI, shared components, and adjacent flow steps the scenario depends on. - **A. FEATURE / SCREEN / FLOW / UI ENDPOINT (directory, branch, diff, PR, page URL)** — perimeter = the feature's screens/components + the routes that render them + the forms and modals inside the flow + entry preconditions (authentication, pre-populated data). Using `git diff --stat` against the base branch (main/dev