verify-ui-quality

Runs mechanical pre-ship verification of self-built UI across intent, click-paths, browsers, and performance.

1|Updated Jul 13, 2026
One-click install
npx skills add https://github.com/dineshrevunuru/SuperSkills --skill verify-ui-quality-dineshrevunuru
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verify-ui-quality
Source: https://github.com/dineshrevunuru/SuperSkills/tree/main/verify-ui-quality
Command: npx skills add https://github.com/dineshrevunuru/SuperSkills --skill verify-ui-quality-dineshrevunuru

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Self-built UI often ships with spacing drift, missing states, broken click-paths, Safari-only bugs, and slow Core Web Vitals that nobody measured. This Skill runs the full mechanical QA pass a skeptical engineer would run, producing a findings log of measured-vs-expected values instead of vague impressions. ## Core Features & Use Cases - Four ordered passes: fresh-eyes intent diff against the spec, automated click-path and state-consistency testing, a cross-device/cross-browser matrix, and a front-end performance pass covering Core Web Vitals, jank, layout thrash, and bundle size. - Scope decision tree: LIGHT for throwaway prototypes, STANDARD for internal tools, FULL for anything external-facing, so verification effort matches risk. - Neutral findings log: every row records expected value with source, measured value, and evidence, then hands off to craft-critique for severity and verdict. - Use Case: After building a portfolio case-study page, run a FULL verification to catch a 3.4s LCP caused by an unoptimized hero image, a missing focus-visible state on nav links, and a Safari backdrop-filter failure before a recruiter ever sees it. ## Quick Start Verify this page before ship: run the full pre-launch check on my production build and report every measured deviation from the design spec.

Frequently Asked Questions about verify-ui-quality

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I QA a web page before shipping it?

Run four ordered passes: measure spacing, type, and states against the spec; drive every click-path with browser automation while checking console and network; test a mobile/tablet/desktop and Chrome/Safari/Firefox matrix; then audit Core Web Vitals, jank, and bundle size on a production build.

How to test Core Web Vitals with Lighthouse?

Run Lighthouse against a production build with mobile throttling (4x CPU, Slow 4G) and record LCP, INP, CLS, and TBT with their named culprits. Good thresholds are LCP at or under 2.5s, INP at or under 200ms, and CLS at or under 0.1.

Should I verify UI on the dev server or production build?

Always run performance verification against a production build or deployed URL, because dev-server numbers are noise. Dev servers add unminified code, source maps, and hot-reload overhead that distort LCP, TBT, and bundle size measurements.

Does this skill replace an accessibility audit?

No. It checks that focus-visible and other states exist as one mechanical pass, but the full accessibility method belongs to a dedicated audit-accessibility skill, which FULL scope invokes separately and links as its own report.

When should I skip full UI verification?

Skip full verification for throwaway prototypes testing a hypothesis, where only the intent diff and happy-path click-through are worth running. Also skip it when nothing renders yet, since fixing build errors is debugging, not verification.