Validate UI Visuals with Precision

This skill acts as a rigorous, skeptical visual validation gatekeeper for UI modifications, built on the default assumption that a modification goal has NOT been achieved until visual evidence proves otherwise - it explicitly ignores code hints or implementation details and judges only what's visible in screenshots. Its eight-step analysis process moves through objective description (state exactly what's observed, no assumptions), goal verification (compare each visual element against the stated goal), measurement validation (confirm rotation/position/size/alignment changes with actual measurement, not impression), reverse validation (actively look for evidence the modification failed), critical assessment (question whether "different" really means "correct"), accessibility evaluation, cross-platform consistency checks, and edge-case/error-state analysis.

It covers modern visual testing tooling (Chromatic and Storybook visual testing for components, Percy and Applitools for cross-browser comparison, BackstopJS/Playwright/Cypress/Jest Image Snapshot for regression testing), design system validation (component library compliance, design token accuracy, typography/color/spacing system adherence), deep accessibility visual verification (WCAG 2.1/2.2 compliance, color contrast measurement, focus indicator visibility, high-contrast and reduced-motion testing), cross-platform consistency (responsive breakpoints, PWA, email client, print stylesheet verification), and CI/CD-integrated automated visual testing (GitHub Actions screenshot comparison in PR workflows). A mandatory 13-item verification checklist and explicit "forbidden behaviors" (assuming code changes automatically produce visual results, accepting "looks different" as "looks correct," quick conclusions without systematic analysis) enforce the skeptical stance.

Use this skill as the final check on whether a UI modification actually works as intended - validating accessibility contrast on a new component, confirming responsive navigation collapses correctly at breakpoints, checking animation smoothness across browsers, or verifying a design system implementation against its spec. It's meant to be the gatekeeper step after implementation, not a design or code-writing tool itself.

It requires actual visual evidence (screenshots, rendered output) to operate on - it explicitly will not accept code changes alone as proof that a visual goal was met, and its output must start with "From the visual evidence, I observe..." rather than inferring results.

Input is a UI modification goal plus visual evidence (screenshots, rendered pages, before/after comparisons). Output is a structured verdict - goals achieved, partially achieved, or not achieved - backed by objective visual measurements, an accessibility assessment, documented edge cases, and specific remediation recommendations when issues are found; uncertainty is stated explicitly rather than papered over.

References modern visual testing tools (Chromatic, Percy, Applitools, BackstopJS, Playwright, Cypress, Jest Image Snapshot, Storybook) and CI/CD integration patterns (GitHub Actions screenshot comparison in pull requests) as the tooling ecosystem this validation approach applies within.

QA engineers, designers, or developers who need an uncompromising, evidence-based final check that a UI change actually achieved its visual and accessibility goals, rather than assuming a code change worked because it "should have."