ux-audit

Audit a UI surface against Designing Interfaces patterns and UX checklists across static, visual, and dynamic layers.

74|11|Updated Jul 4, 2024
One-click install
npx skills add https://github.com/OpenSourceAGI/qwksearch-research-agent --skill ux-audit-opensourceagi
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ux-audit
Source: https://github.com/OpenSourceAGI/qwksearch-research-agent/tree/main/apps/qwk-in-lobe/.agents/skills/ux-audit
Command: npx skills add https://github.com/OpenSourceAGI/qwksearch-research-agent --skill ux-audit-opensourceagi

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? UX reviews are often ad-hoc and inconsistent, missing entire classes of issues like absent capabilities, misleading empty states, or performance regressions. This Skill provides a repeatable, evidence-based audit process for one screen at a time, benchmarking against the Designing Interfaces pattern language and a shared UX checklist so findings are grounded in code lines, screenshots, or measured metrics rather than opinion. ## Core Features & Use Cases - Three-layer audit: L1 static code reading for missing states and patterns, L2 screenshot-based visual review for hierarchy and responsive behavior, and L3 dynamic journey automation with CLS/LCP/INP instrumentation via agent-browser over CDP. - Pattern catalog benchmark: Walks Jenifer Tidwell's pattern families (navigation, layout, input, feedback, data display) to tag patterns as solid, partial, or absent-but-expected. - Closed-loop feedback: Generalizable gaps and exemplary good cases are fed back into the companion ux skill checklists, and each audit is saved as a worked example for future runs. - Use Case: Run an L1 audit of a settings page to catch a fetch with no error branch that renders a permanent skeleton, then confirm the visual hierarchy with L2 screenshots before filing ranked findings. ## Quick Start Ask the agent to run a ux-audit on a specific page or surface, optionally scoping it with --l1, --l2, or --l3 to choose the audit layer.

Frequently Asked Questions about ux-audit

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

FAQPage Schema
How do I run a UX audit on a single page or surface?▼

Invoke the ux-audit skill with the target page or surface, optionally scoping with --l1, --l2, or --l3. L1 static code reading runs on every audit; add L2 for rendered visual checks and L3 for journey automation and performance metrics.

What is the difference between the L1, L2, and L3 audit layers?▼

L1 reads code to find missing states and absent patterns, L2 inspects screenshots for visual hierarchy, spacing, and responsive issues, and L3 drives the real user journey via agent-browser CDP to force error states and measure CLS, LCP, and INP. A verdict must come from the layer that can actually see it.

Can a UX audit conclude visual issues from reading code alone?▼

No. The skill explicitly forbids ticking visual verdicts like dominant control or empty-state quality from code props such as variant attributes. Those are L2 verdicts that must be confirmed on a verified screenshot, and metrics like CLS require L3 instrumentation.

How does the audit measure CLS and other web performance metrics?▼

L3 injects a PerformanceObserver via agent-browser eval before triggering the surface, accumulating layout-shift entries into a window variable read after the surface settles. The same pattern covers LCP, long tasks, and INP, with Core Web Vitals thresholds applied for verdicts.

What are the limitations of a static code-only UX review?▼

A code-only read is blind to entirely absent capabilities, since a missing affordance leaves no file or line to grep. The skill requires benchmarking the surface class against comparable mature products first, then checking each expected capability as present or missing.