agentsclimarketplace
Sign in

Frontend visual qa

Skill ytvee-dev/webdev-agent-kit/skills/frontend-visual-qa

Verify rendered frontend evidence after implementation, including screenshot comparison, responsiveness, overflow, visible states, and scoped visual regression. Use available browser tooling only; exclude static lookup, routine code review, lint, builds, onboarding, and tool detection.From its SKILL.md

Install
npx -y skills add ytvee-dev/webdev-agent-kit --skill frontend-visual-qa

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

8.1 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Frontend Visual QA

Purpose

Verify a rendered frontend implementation against a Design Implementation Spec, Design Direction Contract, and supplied visual references when the task needs browser-rendered visual evidence.

This skill is not a general style-inspection tool. It exists for screenshot comparison, responsive rendering, visual regression evidence, visible state verification, and bounded repair loops when the implementation task includes fixes.

When To Use

  • After implementation when visual acceptance requires comparing the rendered page with supplied screenshots or visual references.
  • When the user asks to run visual QA, capture desktop/mobile screenshots, or compare rendered output to a design reference.
  • When the issue is visibly rendered: responsive layout, wrapping, overflow, clipping, occlusion, viewport fit, visible interaction states, or screenshot-backed visual regression.
  • When console or runtime errors must be checked because they affect the rendered UI during visual QA.
  • When a loop contract says to repair material visual deviations and rerun rendered evidence.

When Not To Use

  • Documentation-only, skill-only, backend-only, or static code review tasks.
  • Design intake before implementation. Use design-screenshot-spec.
  • Live Figma inspection or Figma MCP workflows.
  • Font-family, font-size, font-weight, line-height, color, spacing, CSS variable, or token checks when values can be read from source files, copied inspect values, or the Design Implementation Spec.
  • Computed-style checks whose only purpose is to read typography or token values.
  • Routine lint, typecheck, build, refactor, onboarding, stack detection, or MCP detection.

Required Context

  1. Read AGENTS.md.
  2. Read common/rendered-visual-verification-policy.md.
  3. Confirm the classified task is visual-qa and specifically needs rendered visual evidence.
  4. Read common/approved-patterns.md.
  5. Read common/anti-patterns.md.
  6. Read common/mobile-responsive-rules.md when responsive behavior is in scope.
  7. Read common/verification-loop-rules.md and common/bounded-retry-rules.md when visual repair is in scope.
  8. Read project/verification-profile.md when present.
  9. Read the Design Implementation Spec, Design Direction Contract, visual references, changed files, and relevant routes or pages.
  10. Read references/visual-qa-checklist.md.

Tool Contract

  • Use Browser or Playwright MCP only for rendered visual QA tasks allowed by common/rendered-visual-verification-policy.md.
  • Browser or Playwright MCP availability means the tool is callable in the current agent session. A running local server or an installed Playwright dependency does not count as MCP availability.
  • Do not replace a missing configured Browser or Playwright MCP with local Playwright package usage unless the user explicitly approved that fallback for the current task.
  • Use Visual Diff MCP when available to compare implementation screenshots with supplied references.
  • Use Visual Reference MCP when available to access supplied images.
  • Use mdn only when web platform behavior affects a visual QA finding.
  • Do not use Figma MCP.
  • If Browser or Playwright MCP is unavailable, report which rendered checks are blocked and complete only the non-rendered checks that can be run honestly.

Workflow

  1. Identify target routes, pages, components, states, and viewports from the spec.
  2. Confirm the task is in the allowed rendered visual QA spectrum.
  3. For typography, spacing, color, and token questions, inspect the spec, copied values, CSS, tokens, and component styles first. Do not open Browser or Playwright just to read computed styles.
  4. Start or reuse the local app with the project's normal development or preview command only when rendered visual evidence is in scope.
  5. Open the rendered target in Browser or Playwright MCP only when that MCP tool is available and the task is in scope.
  6. Check console and runtime errors only when they affect the rendered visual QA scope.
  7. Verify desktop, tablet, small phone, and landscape behavior when those viewports are in scope.
  8. Capture implementation screenshots when visual comparison or evidence is in scope.
  9. Compare screenshots against visual references with Visual Diff MCP when available; otherwise perform manual comparison using the checklist.
  10. Exercise relevant hover, focus, selected, disabled, loading, empty, error, and interaction states only when provided by the spec or visible acceptance criteria.
  11. If visual repair is in scope, list material deviations, fix scoped deviations, rerun rendered checks, and apply bounded retry rules.
  12. Do not use a visual repair loop as permission for broad redesign, new design direction, package installation, or unrelated layout cleanup.
  13. Hand off material quality, architecture, TypeScript, security, or performance concerns to frontend-quality-reviewer instead of treating visual QA as a broad code review.

Output Contract

Final response: return only facts that affect the user's understanding, confidence, or next action. Omit empty fields and workflow narration.

Report:

  • rendered visual QA scope;
  • routes or pages verified;
  • viewports checked;
  • interactions or states checked;
  • console/runtime findings when in scope;
  • visual diff result or manual comparison summary;
  • attempts when visual repair was in scope;
  • static style checks used instead of browser tooling, when applicable;
  • fixed issues or remaining deviations;
  • blockers and unavailable tools.

Validation Gates

  • Browser or Playwright must be used only for rendered visual QA tasks named in common/rendered-visual-verification-policy.md.
  • A local Playwright package, lockfile entry, or running local server must not be reported as Browser or Playwright MCP availability.
  • Font and token checks must prefer source files, copied inspect values, and specs over computed styles.
  • A visual QA pass must include rendered browser evidence unless blocked.
  • Visual repair attempts must be bounded and scoped to acceptance criteria.
  • Static typecheck, lint, or build alone is not visual QA.
  • Rendered verification is QA evidence, not a testing workflow.
  • Material visual mismatches must be reported with the affected viewport or state.
  • No Figma MCP use is allowed.

Trigger Evals

Should trigger:

  • "Check the implemented page at desktop and 375px against these screenshots."
  • "Verify overflow, fixed UI, and visible states in the rendered app."

Should not trigger:

  • "Read the font token from this CSS file."
  • "Detect whether Playwright MCP is installed during onboarding."

Reference Map

  • common/rendered-visual-verification-policy.md
  • common/mobile-responsive-rules.md
  • common/verification-loop-rules.md
  • common/bounded-retry-rules.md
  • references/visual-qa-checklist.md

What ships with it: 2 files

4.2 KB alongside SKILL.md

agents/

references/

Gives 0 of the 12 instructions most quality gates skills give in ~1.4k tokens

Counted across 1,524 of the 2,830 authors here whose files we hold, read 2026-09-06

  • Read full output and check exit codein 45 of 1524, across 40 files
  • Verify output confirms the claimin 44 of 1524, across 39 files
  • Identify the command that proves the claimin 43 of 1524, across 39 files
  • Execute the full verification commandin 36 of 1524, across 30 files
  • Produce a verification reportin 34 of 1524, across 18 files
  • Review git diff changesin 30 of 1524, across 16 files
  • Fix build failures immediatelyin 29 of 1524, across 9 files
  • Group findings by severityin 28 of 1524
  • State claim only with evidencein 27 of 1524, across 22 files
  • Verify regression tests with red-green cyclein 26 of 1524, across 22 files
  • Run the full test suitein 26 of 1524, across 25 files
  • Run test suite with coveragein 25 of 1524, across 10 files

Said here and by no other author read

  • Verify rendered output against design specifications
  • Use Browser or Playwright MCP for rendered visual evidence
  • Inspect source files for typography and token values
  • Check console errors affecting rendered UI
  • Verify responsive behavior across specified viewports
  • Exercise interaction states defined in acceptance criteria

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.