Playwright Flow Runner

Drives a real browser through a defined user journey and reports, step by step, whether the app actually did what it was supposed to — with evidence, not just a vibe.

If the user hasn't told you what to test yet and instead wants to figure out what's worth testing on a site, that's the scenario-mapper skill's job, not this one — it explores a site and produces a prioritized CSV of candidate scenarios. Use its output as the step plans you execute here. If a scenario already has a detailed, persistent test-case document from test-case-writer, use that directly as your plan rather than writing your own — see step 1 below.

Before touching the browser: check what you have

You're on Claude Code, so you likely have two ways to drive Playwright:

• @playwright/cli — shell commands, writes accessibility snapshots and screenshots to disk instead of streaming them into your context. Check for it first: npx @playwright/cli --help. If it's there, prefer it — a typical flow costs a fraction of the tokens this way, and disk artifacts survive after your context window doesn't.
• Playwright MCP server tools (browser_navigate, browser_click, browser_type, browser_snapshot, browser_take_screenshot, browser_wait_for, browser_evaluate, browser_network_requests, browser_console_messages, browser_tabs, and similar) — use these if the CLI isn't installed, or if you're in an MCP-only context. Check your actual connected tool list for exact names rather than assuming — server versions drift.

Don't guess which one is available — check, then commit to one for the whole run. Mixing them mid-flow is a good way to lose track of session/auth state.