From frontend-visual-qa
Audits rendered web, desktop, and browser-based UIs using real-browser journeys, screenshots, DOM geometry, and Playwright. Use after UI implementation to find visual defects.
How this skill is triggered — by the user, by Claude, or both
Slash command
/frontend-visual-qa:frontend-visual-qaThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Audit the interface the user can actually see. Treat build success, DOM presence,
evals/evals.jsonevals/files/browser-output-fixture.htmlevals/files/data-viz-reference.htmlevals/files/data-viz-target.htmlevals/files/deck-fixture.htmlevals/files/gis-fixture.htmlevals/files/layout-defects.htmlevals/files/route-state-fixture.htmlevals/files/script-evidence-edge-cases.htmlevals/files/static-review.pngevals/files/transient-fixture.htmlevals/trigger-evals.jsonreferences/data_viz_tier_and_token_audit.mdreferences/history-derived-checklist.mdreferences/journey-and-page-contracts.mdscripts/visual_layout_audit.mjsAudit the interface the user can actually see. Treat build success, DOM presence, and uninspected screenshot files as supporting signals, never as visual proof.
Default to audit-only. Do not edit implementation, add tests, install dependencies, or update snapshots unless the user explicitly asks to fix or change the UI.
Use this skill only after a rendered artifact exists. Select the smallest audit profile that covers the request:
Combine profiles only when the changed surface or the user requests a broad release review. Do not force a local line-break review through unrelated auth, map, export, and native-shell checks.
Use adjacent skills by stage:
Produce all of the following:
Never downgrade the user's real objective to whatever evidence was easiest to collect.
Track this checklist for nontrivial audits:
- [ ] 1. Establish the audit contract and authorization
- [ ] 2. Select the required evidence level and canonical harness
- [ ] 3. Prove the route, state, data, and viewport are the intended ones
- [ ] 4. Capture and inspect macro, local, and responsive evidence
- [ ] 5. Exercise the affected journeys and recipient outputs
- [ ] 6. Report findings; fix and re-run only when authorized
Read the project instructions, design-system SSOT, tokens, approved assets, launcher/test SOP, and the changed code. Then write a falsifiable contract:
Artifact/page type:
Actor and job:
Exact route + conditional state:
Reference or design-system SSOT:
Relevant viewport/device matrix:
Intended projection/canvas size, if any:
Affected interactions and outputs:
Audit profiles:
Authorization: audit-only | fix-and-verify
Anti-goals / must-not-become:
Pass condition:
Name the correct state before judging pixels. Logged-out, onboarding, empty, permission-denied, seeded, populated, loading, and feature-flag branches can look like different products. A clean screenshot of the wrong branch is invalid. When authorization is in scope, signed-in-but-role-less is a distinct branch; logged-out or fully privileged evidence cannot stand in for it.
Use the actor's task as the success target. “The chart exists” or “the tab switches” is not enough when the user needs to decide severity, finish a review, or recover from an error.
Use the strongest level required by the claim:
| Level | Evidence | Claims it can support |
|---|---|---|
| A | Real visible Chrome/browser or canonical native-app window, driven through the user journey | Browser/OS chrome, downloads, clipboard, popup blocking, file pickers/dialogs, print preview, permissions, native shell, actual visible-window complaints |
| B | Same-state browser DevTools or project E2E/Playwright run with representative data | DOM geometry, routes, focus, overlays, interaction states, repeatable responsive behavior |
| C | Fresh headless mechanical sweep from the bundled script | Overflow, wrapping, images, basic layout heuristics, screenshot candidates |
| D | Source, lint, build, unit tests, or static DOM reasoning | Hypotheses and regression support only |
Do not promote a lower level into a stronger conclusion:
If the required Level A surface is unavailable or another session owns the GUI, continue only with evidence that does not pretend to replace it. Report the exact missing evidence and mark the affected claim partial or blocked.
Use the project's canonical launcher and existing fixture/auth path. Do not invent a new server command or silently seed a different state.
Record this state from the rendered page:
() => ({
href: location.href,
title: document.title,
h1: document.querySelector("h1")?.textContent?.replace(/\s+/g, " ").trim() || null,
inner: [innerWidth, innerHeight],
outer: [outerWidth, outerHeight],
clientWidth: document.documentElement.clientWidth,
scrollWidth: document.documentElement.scrollWidth,
overflowX: document.documentElement.scrollWidth - document.documentElement.clientWidth,
visualViewport: visualViewport
? [visualViewport.width, visualViewport.height, visualViewport.scale]
: null,
dpr: devicePixelRatio,
metaViewport: document.querySelector('meta[name="viewport"]')?.content || null,
})
Compare outerWidth, innerWidth, visualViewport, and clientWidth before blaming CSS for blank space or mobile layout. Reset stale zoom/device emulation and re-capture after display or scale changes. Restore the user's expected viewport when finished.
For a scripted sweep, first prove the target state is reproducible with one of:
Otherwise label the run a fresh-session diagnostic, not a pass.
Capture the whole visible composition before zooming into a local defect. Then inspect the affected component and at least one relevant responsive width. Include lower sections for long pages; a clean hero does not validate the rest.
Open every screenshot with an image viewer and record what you saw. Use DOM geometry to explain a visible problem, not to replace visual judgment.
Check at minimum:
Load references/history-derived-checklist.md for the core visual/responsive defect catalog and standards-backed checks.
Run the bundled sweep from the audited project so it can resolve the project's existing Playwright dependency:
node <skill-root>/scripts/visual_layout_audit.mjs \
--url http://127.0.0.1:5173/ \
--page-type app \
--require "Expected state marker" \
--screenshot-sections
Use --file <artifact.html> for a local HTML artifact. Run node /scripts/visual_layout_audit.mjs --help for all flags. For a contracted canvas, pass one or more exact viewports; custom viewports replace the default responsive matrix:
node <skill-root>/scripts/visual_layout_audit.mjs \
--file deck.html --page-type deck --viewport 1920x1080 \
--screenshot-sections
Use repeated --forbid patterns only for project-specific stale names or rendered terms that the current product contract explicitly prohibits. Do not encode generic taste preferences as forbidden regexes.
The script exits:
The script writes viewport screenshots and frontend-visual-qa-report.json to a unique temporary run directory by default. An explicit --out directory must be new or empty so stale screenshots cannot masquerade as current evidence. It is a Level C sweep, not the final verdict.
Do not mutate the audited project merely to run the sweep. Reuse its package manager and canonical browser harness. If Playwright is absent, continue with available Level A/B evidence and report the omitted Level C sweep; install a dependency only when dependency changes are authorized.
Exercise only the relevant transition matrix:
entry -> ready -> active -> processing -> success/error -> recovery -> ready
Also verify, when applicable:
Load references/journey-and-page-contracts.md when the audit includes state transitions, authorization, modes, provider/model/runtime truth, routes, transient states, overlays, browser outputs, native shells, landing/deck/browser tool/game artifacts, dashboards, design-system artifacts, GIS/maps, or review tools.
Load references/data_viz_tier_and_token_audit.md only for reporting-grade data pages, named tier/reference comparisons, chart token audits, or categorical palettes.
Before reporting a nontrivial audit, re-walk the primary path as a tired user without debugger context. Look first for unclear trigger or mode ownership, hidden return-to-default, blocked recovery, misleading runtime labels, raw machine language, unreachable controls, avoidable manual work, and the missing guard that would let the same defect recur. This is a falsification pass, not an excuse to expand a local visual-only audit into every profile.
Separate impact from category. Follow the project's severity taxonomy when one exists. Otherwise use:
Use categories such as layout, responsive, state, route, accessibility, browser-output, native-shell, intent, or taste. Taste and Intent are not severity levels.
Report with this compact schema:
Status: verified | partial | blocked
Scope: <artifact, route/state, viewports, profiles>
Findings:
- Major · browser-output · PDF action · desktop
Evidence: clicking the visible control opens about:blank; print preview has no page.
Fix: use a user-gesture-safe print path and re-test the recipient preview.
Verified:
- <journey/state/viewport + concrete evidence>
Not verified:
- <missing surface/evidence and why>
In audit-only mode, stop after the evidence-backed report. In fix-and-verify mode:
Call the audit verified only when:
Otherwise report partial or blocked. Never ask the user to perform a check the available agent tools can perform.
npx claudepluginhub p/daymade-frontend-visual-qa-frontend-visual-qaAudits web app UX by dogfooding as user persona: tracks emotional friction, click efficiency, resilience to back/refresh, return intent. Uses Playwright/Chrome MCP for live sites, outputs ranked reports.
Verifies UI modifications through screenshot analysis, visual regression testing, and design system compliance. Useful for validating that visual changes meet their intended goals.
Audits built React/Next.js frontends for user-facing defects in code and rendered UI. Returns file:line findings and a ship verdict for PRs and components.