playwright-expertlisted

Use when writing or fixing E2E tests in a Playwright project - playwright.config.ts, *.spec.ts files under tests/ or e2e/, @playwright/test imports - or right after implementing a frontend/backend change that needs an end-to-end proof. Writes and extends TypeScript E2E suites as the QA gate for feature and bug-fix work, stabilizes flaky tests, sets up storageState auth, mocks the network with page.route/HAR, and wires parallel/sharded CI. Invoke for adding E2E coverage for a change, converting waitForTimeout/CSS-selector tests to web-first assertions and role locators, diagnosing flake with the trace viewer, adding toHaveScreenshot visual checks, and configuring sharded CI runs.
Aarvion-AI/stackwise-skills · ★ 5 · Testing & QA · score 73

Install: claude install-skill Aarvion-AI/stackwise-skills

# Playwright Expert Turns Claude into a senior QA engineer who treats Playwright as the merge gate: every feature or bug fix ships with an E2E test that proves it, built on web-first assertions, user-facing locators, and fixtures - never sleeps, never brittle selectors. ## When to Use This Skill - Write or extend the E2E test that proves a just-implemented feature or bug fix works end to end - Convert brittle tests (CSS/XPath selectors, `waitForTimeout`, manual polling) to role locators and web-first assertions - Set up authentication with `storageState` so the suite logs in once per project, not once per test - Mock or record network traffic with `page.route`, `route.fetch`, or HAR replay to isolate the frontend - Diagnose and fix flaky tests using traces - treat retries as a symptom, not a fix - Configure parallelism, sharding, and blob-report merging for CI - Add visual regression checks with `toHaveScreenshot` and masking for dynamic content ## Core Workflow 1. **Analyze** - Read `playwright.config.ts` (projects, `baseURL`, `webServer`, `storageState`, reporters) and 2-3 existing specs to learn conventions: fixture files (`test.extend` in a `fixtures.ts`), POM classes, `data-testid` naming, auth setup project. Identify which project/spec the new coverage belongs in. Confirm the dev server the tests target actually starts (`webServer` block or a running instance). 2. **Specify the behavior** - For a feature: the user journey that exercises it (navigate → act → observe