cross-browser-matrix
Playwright Cross-Browser / Responsive Matrix
Takes a scenario you already have a plan for and runs it repeatedly across engines and viewport sizes, then collapses the results into one table instead of N separate reports you'd have to compare by hand.
Before you start — read this one carefully, it changes the approach
Browser engine and viewport are not the same kind of dimension. Viewport size is freely adjustable within a single session — resize the context, no restart needed. Browser engine, if you're going through the official Playwright MCP server, is set at server launch (--browser flag or config), not per tool call — one running MCP server instance drives one engine for its whole session. This means the straightforward "just call a tool with a different browser argument" approach that works for viewport does not work for engine on the standard MCP setup.
Given that, and that you're on Claude Code with bash access: for the engine dimension specifically, prefer writing and running a small standalone script (Node with the playwright package, or Python with playwright.sync_api) that loops chromium.launch() / firefox.launch() / webkit.launch() directly, rather than trying to reconfigure or juggle multiple MCP server instances mid-conversation. This isn't the token-efficiency preference from the other skills in this toolkit — it's a hard functional constraint, not a nice-to-have. If you're on a community MCP server variant that does expose per-call browser selection, or you've deliberately got multiple MCP server instances running (one per engine), that works too — check what's actually in front of you before assuming either way.
Know what "Chrome," "Edge," "Chromium," "Firefox," and "WebKit" actually mean here. Chrome and Edge are both channels of the Chromium engine, not separate rendering engines — testing both catches almost nothing that testing Chromium alone wouldn't, since the underlying engine is the same. Chromium, Firefox (Gecko), and WebKit are three genuinely different engines. If you're prioritizing a limited matrix, that triad is where the real coverage is; Chrome/Edge beyond plain Chromium is a low-value addition unless you have a specific reason to think a browser-specific feature (not the rendering engine) is involved.
Desktop WebKit is an approximation of Safari, not Safari itself — say so in the report. Playwright's WebKit build tracks desktop Safari's engine reasonably well but isn't identical to real Safari, and is a bigger gap from real iOS Safari specifically (viewport units, on-screen-keyboard behavior, and PWA quirks all diverge on real iOS hardware). Report results as "WebKit engine," not "verified on Safari" or "verified on iPhone" — the difference matters to whoever reads the report and decides whether to trust it for a mobile-Safari-specific concern.
Relationship to the other skills
This doesn't discover scenarios (scenario-mapper's job) or invent new assertions (flow-runner's job) — it takes a scenario's existing step plan and expected outcomes and runs them, unmodified, once per matrix cell, using the same wait-for-state-and-assert discipline as flow-runner. If a cell fails, capture evidence the same way flow-runner does; if the failure needs deeper investigation, hand it to bug-triage same as any other failure would go.