Audits already-rendered web, landing-page, HTML deck/slide, browser tool/game, dashboard/admin, design-system, and desktop UIs using real-browser or native-app journeys, inspected screenshots, DOM geometry, responsive or projection viewports, and a bundled Playwright sweep. Use after UI implementati

Frontend Visual QA Audit 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. Permission to fix source does not authorize rebuilding, restarting, or deploying any target. Scope And Routing Use this skill only after a rendered artifact exists. Select the smallest audit profile that covers the request: core visual — composition, typography, spacing, wrapping, clipping, images; responsive — breakpoints, reflow, mobile alternatives, scroll ownership; state and journey — conditional branches, transitions, recovery, routes; browser output — download, share, clipboard, popup, file dialog, print, PDF; native shell — Electron or hybrid chrome, permissions, drag regions, IPC UI; page contract — dashboard/admin, landing/deck, design system artifact, browser tool/game, map/GIS, or review tool; reference parity — comparison with a named screenshot, product, or tier; data visualization — chart hierarchy, tokens, semantics, and accessibility. For a specific task/object link handoff, select state and journey for that destination, including authoritative machine and run/job identity when titles repeat. Keep the audit bounded to the promised destination. For a website/document converted to Markdown, or an illustrated transcript/note consumed in Obsidian or another named reader, load [references/markdown reader handoff.md](references/markdown reader handoff.md) before judging figure readability. Compare the complete source figure with its actual document reading canvas, including HTML captions and SVG/CSS dependencies. For oversized embedded images, use its display size recipe and test a representative long image with the adjacent text before applying the same layout to the document. 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: Use ui designer, frontend design, or another design skill to derive or create a visual direction, or to extract a design system from reference screenshots — this skill audits an already rendered artifact, it does not derive one. Use this skill to test the already rendered result, not to debug nonvisual code (logic, data, or backend correctness) that produced no visible defect. Use qa expert for a full test strategy, defect program, and release metrics. Use both this skill and qa expert only when rendered visual evidence is one part of a broader QA gate. This skill owns rendered information hierarchy as well as geometry: whether persistent labels, explanations and repeated context help the actor's task or displace it. Do not route that question away as mere copy polish. Domain fact correctness, terminology and persuasion still need the appropriate content or subject matter review; a rendering pass cannot certify those claims. Required Outcome Prepare before taking over the target The executing auditor resolves the latest user contract and stage specific Skills before driving a shared browser or device. Load the Skills explicitly requested for this task from their actual entries. For numerical breakdowns or charts, also use data visualization discipline; for Android control, use android automation alongside this visual audit. Add a design Skill only when the user requests it or the task changes design. Device control alone supplies no visual or business acceptance criterion. Read the selected current Skill text and affected references, then freeze the actor's question, canonical target, affected states and observable answer. A catalog entry, remembered section label or compaction summary is a locator, not the loaded instructions. Reuse unchanged text still present in context; after compaction, reload only the needed instructions rather than rerunning completed tests. Record this preparation in the existing scope contract: required capability, resolved owner/entry, and the acceptance evidence it supplies. Missing instructions leave the dependent judgement unverified; continue authorized independent read only work. Finish tool/dependency preparation before a short shared resource window, and follow the target control owner's restoration contract when that window ends. These are auditor actions, not claims of an automatic Skill loading guard. Produce all of the following: 1. A scope contract naming the artifact, actor, job, target kind and canonical target identity, conditional state, viewports, affected journeys, reference/SSOT, and authorization. 2. A verification status: verified , partial , or blocked . 3. Findings tied to visible evidence, impact, state, viewport, and reproduction. 4. A list of what was actually exercised and what remains unverified. 5. When freshness or deployment is claimed, a separate delivery status and its identity evidence; when target mutation is explicitly authorized, identity before/after, a same target/state/viewport re run, and a regression guard. Never downgrade the user's real objective to whatever evidence was easiest to collect. Workflow 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 target, state, data, viewport, and claimed freshness [ ] 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 1. Establish The Audit Contract 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: Target kind + canonical identity: web = exact in browser URL (query/fragment included) + named environment single file/image = canonical path + content hash + rendering scheme multi resource artifact = canonical entry + dependency/manifest digest + renderer native = installed artifact fingerprint + build/version + process/window + renderer route Conditional state: Delivery identity/status, only when freshness/deployment is claimed: Reference or design system SSOT: Relevant viewport/device matrix: Intended projection/canvas size, if any: Affected interactions and outputs: Audit profiles: Source authorization: audit only fix and verify Interaction/action authority: read only navigation fixture safe state changes <named actions Target mutation authority: none isolated diagnostic local target deploy <named environment 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. Freeze the user's requirements separately from the implementation. A complaint about clutter, redundant explanation or wasted space identifies a failure class, not just the circled element. Inspect that class across the declared full surface. Do not silently narrow the review to the last screenshot's rectangles or rewrite the requirement as “the task remains possible” after a candidate fails. When the pass condition names a visual reference — a screenshot, another product's page, a "make ours look like theirs" — load [references/reference parity decomposition.md](references/reference parity decomposition.md) before judging the implementation, and in fix and verify mode before writing the next fix round . This does not widen the skill's after implementation scope: the decomposition is the first act of the audit , applied to the reference artifact (which always already exists), and each parity fix round is implementation happening inside this skill's fix and verify authority. If the same request also needs a visual direction created from scratch, that part still belongs to a design skill — hand the finished inventory over rather than re deriving it there. The contract's first deliverable is the measured structural inventory of the reference, and the parity verdict is a per relationship diff against that inventory. Fixing only the delta the user's latest screenshot complains about, round after round, converges only by exhausting the user — a real five round case is decomposed in that file. It also governs two traps that outlive the inventory: your own geometry assertions are Level D for parity (they encode your reading of the reference, and stay green through a misreading), and a user's veto on an effect ("never crop the image") indicts the structural premise that forces the effect, not the parameter that picks its flavor. For a reporting grade data page compared against a tier reference, that file and [references/data viz tier and token audit.md](references/data viz tier and token audit.md) divide the work: decomposition governs page structure, the tier benchmark governs data presentation parameters — load both. 2. Select The Evidence Level 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: A screenshot path that was never opened has no visual evidence value. A fresh headless empty state cannot verify the user's populated state. A renderer URL cannot verify an Electron/native shell. A handler call cannot verify Chrome print preview, popup, or download UI. A pointer cursor, hover style, or "click to X" badge cannot verify the click does anything: a signifier without a working handler is a dead click, confirmed only by triggering it (step 5). Device emulation is an approximation; use a real device when device specific behavior is material. 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 . 3. Prove Target, State And Viewport Read project authoritative status before launching anything. Use the canonical launcher only when each side effect fits its own authority: lifecycle permission covers rebuild/restart/deploy, while seed or transactional data changes require interaction/action authority. Never infer one from the other. An authorized isolated diagnostic server is labeled non target. Keep an exact web URL in browser memory, but persist only a redacted structural URL plus a stable digest/query key list. Single files/i

frontend-visual-qa