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.