From frontend-visualqa
Verifies running frontends via screenshot-backed visual claims, viewports, and evidence for UI states, visibility, clipping, responsive behavior, and interactions after code changes.
How this skill is triggered — by the user, by Claude, or both
Slash command
/frontend-visualqa:frontend-visualqa [url] [claims or QA task][url] [claims or QA task]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill after changing UI code when DOM assertions are not enough and you need screenshot-backed proof of what the page actually rendered.
Use this skill after changing UI code when DOM assertions are not enough and you need screenshot-backed proof of what the page actually rendered.
Use it for:
Do not use it for:
frontend-visualqa MCP tools when available. They keep browser state warm across calls.manage_browser with action="login" and the login URL. That opens a persistent headed browser the user can authenticate in. Reuse the same session_key afterward, and call manage_browser(action="close", ...) when you are done with the authenticated session.verify_visual_claims — it captures screenshots internally, so a separate take_screenshot is redundant.take_screenshot first when you have no claims yet and need to see the page before writing them.Claims must be observable from pixels. Open references/claim-writing.md for examples and anti-patterns.
If a claim requires interaction before it becomes true or false, pass a navigation_hint. Keep the claim focused on the final visible state instead of burying a multi-step script inside the claim text.
For multi-claim flows where only some claims need setup, prefer a claims file and put per-claim metadata under the specific bullet, for example:
- After logging in, the dashboard shows "Welcome back, Developer"
- navigation_hint: Type "[email protected]" in the email field, type "password123" in the password field, then click Continue.
- The API Calls Today stat card shows the value 1,247
When using MCP, split warm-session verification into successive verify_visual_claims calls if the setup differs between claims. Do not expect one global navigation hint to apply selectively within a single batch.
Use ephemeral mode for public pages and quick checks.
Use persistent mode for auth-gated apps, multi-step flows, or any case where cookies and local storage must survive across runs. In MCP-driven workflows, bootstrap auth with manage_browser(action="login", ...) before running claims.
Setup and client-specific install commands live in references/install.md.
The detailed QA playbook, status meanings, and recovery steps live in references/protocol.md.
Every tool response includes file paths to screenshot evidence. Always surface this proof — do not just summarize the text result.
verify_visual_claims returns an artifacts_dir and, for each claim, results[].proof.screenshot_path (the decisive screenshot) and results[].proof.text (a textual summary). Additional screenshots from intermediate steps live in results[].trace.screenshot_paths.
take_screenshot returns a screenshot_path.
After a verification run:
If your client cannot display images inline, print the absolute path so the user can open it manually.
Prefer the tools in this order:
verify_visual_claims when the user provides claims — this is the primary tool and captures its own screenshotstake_screenshot only when you need to see the page before you can write claimsmanage_browser when the shared browser state is stale, wrong-sized, or needs resetIf the MCP server is not available, use the CLI fallback in references/install.md.
$ARGUMENTS
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub yutori-ai/frontend-visualqa --plugin frontend-visualqa