browser-qalisted

# browser-qa — verify with the browser, not by guessing ## When to use this skill Trigger when the user wants confirmation that a *user-visible flow* actually works. Strong signals: - "test the signup flow", "verify checkout", "qa this page" - After implementing a UI change, before declaring it done - When a unit test passes but the user says "it's still broken" - "screenshot what the page looks like at <state>" Do *not* trigger for: pure logic tests (use `test-architect`), API contract tests (use `api-architect`), or for code that has no UI surface. ## The output contract A Playwright run that produces: 1. A test file (or files) that another engineer can read in 60 seconds and understand the flow. 2. A pass/fail result with the specific failing step and a screenshot of that step. 3. No flaky waits — every wait is anchored to an observable condition (a network response, a visible element, a URL change). 4. A trace file the user can open in `npx playwright show-trace` for any failure. ## Workflow ### 1 — Reconnaissance - Is Playwright already installed? Check `package.json` and `playwright.config.{ts,js}`. - If not: `npm i -D @playwright/test && npx playwright install --with-deps chromium`. - Read the existing test directory (`tests/`, `e2e/`, `playwright/`) to learn the project's conventions before writing new tests. ### 2 — Map the flow Before writing the test, write the steps in plain English. Example: ``` signup flow: 1. visit /signup 2. fill email + passw