Browser QA

You're about to drive a real browser to verify a feature. This skill exists because there are three browser stacks available (Playwright MCP, Claude-in-Chrome MCP, computer-use MCP), they have very different failure modes, and picking the wrong one for the wrong stage of work burns wall clock for no reason.

First-time setup — DO THIS BEFORE ANYTHING ELSE

You will be blocked mid-task if you wait until you need a permission to ask for it. Ask for everything up front, in parallel, in the very first message of the QA phase:

1. Request computer-use access for Chrome by calling mcp__computer-use__request_access with apps: ["Google Chrome"] and a one-sentence reason. Chrome is a tier-"read" app — you'll be able to take screenshots through the OS compositor but not click. That's exactly what you want: real-Chrome screenshots without having to fight focus.
2. Verify the Claude-in-Chrome extension is connected by calling mcp__claude-in-chrome__tabs_context_mcp with createIfEmpty: true. If this returns an error, the extension isn't installed/enabled — stop and ask the user to install it rather than falling back to a worse stack.
3. Verify Playwright MCP works by calling mcp__playwright__browser_close once (no-op if no tab; surfaces "browser already in use" lock errors early so you can pkill -f "mcp-chrome-" before they bite you mid-task).

Do all three in parallel in one message. If anything is missing, surface it immediately — don't start QA half-blind.

When to use which stack

Use Playwright MCP for iterative dev-loop QA — every "did this fix work?" check while you're still building. Reasons: snapshot-aware wait_for, fast happy paths (~10 s for a navigate + click + screenshot), failures are at the prompt layer (wrong URL, short wait threshold) and recoverable by retrying smarter. Headless Chromium screenshots are dense, clinical, and ideal for "is the UI correct?" reviews.

Use Claude-in-Chrome + computer-use for end-of-task artefacts — PR screenshots, demo GIFs, customer bug repros. Reasons: the captured surface is the real Chrome the user sees (tab strip, profile avatar, extensions, DEV stripe, the "Claude is active in this tab group" pill). That matches reviewer expectations. Don't use it for the inner dev loop — it's slower and has runtime-layer failures you can't fix from a prompt.