Use when you need to check browser-specific CSS/layout/JS rendering differences (Chromium/Firefox/WebKit) before shipping a CSS/JS change or investigating compatibility issues across engines. NOT for viewport/breakpoint layout review (use responsive-visual-review), NOT for functional/interaction E2E testing across browsers (use playwright-testing), NOT for designing a polyfill/feature-detection fix.
66
83%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Renders the same pages in Chromium, Firefox, and WebKit at one fixed viewport and diffs what a human would notice — font fallbacks, layout quirks, unsupported CSS features, console errors unique to one engine. Works on any website; no existing multi-browser test setup required, though it will reuse one if the project already has Playwright projects configured per engine.
responsive-visual-review.
This skill holds the viewport fixed and varies the engine instead.playwright-testing / the project's own E2E suite. This skill
never clicks anything — it only compares what renders.@supports
fallback, drop the feature) — that's a design decision for the person
fixing it, not something to prescribe from a rendering diff alone.responsive-visual-review if a recent run
exists (homepage, one content/detail page, one form page, one
long-form/typography-heavy page — 3-5 pages total).responsive-visual-review's breakpoint sweep so the two
skills don't overlap). Add a mobile-width pass only if the site's mobile
experience diverges meaningfully between engines (rare, but WebKit's
mobile emulation quirks are a known exception).For each page, capture a full-page screenshot in each of the three engines at the same viewport:
browser_type per engine, ornpx playwright test --project=chromium --project=firefox --project=webkit
if the project already has a multi-browser Playwright config (check
playwright.config.ts first — most projects only run Chromium by
default; don't assume multi-engine config exists).Name captures <page-slug>-<engine>.png, saved to the scratchpad
directory (throwaway review artifact, not for commit).
Compare the three screenshots per page side by side.
Rendering
:has(), container queries, backdrop-filter,
text-wrap: balance, subgrid, :focus-visible quirks)<select>,
date/time inputs) — Safari and Firefox diverge most hereConsole
Severity-ranked, each with: page, engine(s) affected, screenshot pair
(reference engine vs divergent engine), and a suspected CSS/JS cause
where identifiable — "Safari renders the pricing grid columns unequal
width, likely grid-template-columns: auto interacting with old Safari
Grid auto sizing" is actionable; "looks different in Safari" is not.
| Severity | Examples |
|---|---|
| Critical | Page unusable or content inaccessible in one engine |
| High | Visible layout break, broken form control, engine-unique JS error breaking a feature |
| Medium | Noticeable but non-blocking visual divergence (font rendering, spacing) |
| Low | Cosmetic-only, sub-pixel differences a user wouldn't consciously notice |
Report findings for triage — this skill does not fix the underlying CSS/JS.