
Audit
- 357 installs
- 247 repo stars
- Updated August 4, 2026
- educlopez/ui-craft
audit is a Claude Code skill that runs a technical UI audit of accessibility, performance, and responsive design and outputs a prioritized findings table.
About
This skill runs a technical UI audit across accessibility, performance, and responsive design and produces a prioritized findings table. It is one lens of the broader ui-craft skill and starts with a mandatory visual capture at desktop, tablet, and mobile viewports via Playwright or a browser MCP. A developer invokes it when they ask for an audit of their UI. It checks focus-visible states, keyboard reachability, touch targets, CLS, and mobile-first breakpoints, then reports findings before editing.
- Technical UI audit: a11y, performance, responsive
- Mandatory visual capture at three viewports
- Produces a prioritized findings table
Audit by the numbers
- 357 all-time installs (skills.sh)
- Ranked #720 of 1,880 Design & UI/UX skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
audit capabilities & compatibility
Free; no API key required.
- Capabilities
- ui audit · accessibility review · performance review · responsive review
- Works with
- playwright · chrome
- Use cases
- ui design · code review · web design
- Pricing
- Free
What audit says it does
Technical UI audit — a11y, performance, responsive. Produces a prioritized findings table.
audit is knob-agnostic — accessibility and performance are not tunable.
Do NOT rewrite code unless asked. Report findings first; wait for approval before editing.
npx skills add https://github.com/educlopez/ui-craft --skill auditAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 357 |
|---|---|
| repo stars | ★ 247 |
| Last updated | August 4, 2026 |
| Repository | educlopez/ui-craft ↗ |
How do I find accessibility, performance, and responsive problems in my UI before shipping?
Audit a UI for accessibility, performance, and responsive issues
Who is it for?
Developers who want a structured accessibility, performance, and responsive review of an existing UI.
Skip if: Security or vulnerability testing; this is a UI-quality audit, not a security scan.
When should I use this skill?
When the user asks for an audit on their UI, or mentions 'audit' alongside design, UI, or frontend work.
What you get
A prioritized findings table grouping issues into Critical, High-impact, and Quick wins.
- Prioritized findings table (Before / After / Why)
- Critical, high-impact, and quick-win issue groups
Files
<!-- AUTO-GENERATED. Do not edit here. Source: skills/ui-craft/ + commands/*.md. Regenerate with node scripts/sync-harnesses.mjs. -->
Context: this sub-skill is one lens of the broader ui-craft skill. If the ui-craft skill is also installed, read its SKILL.md first for Discovery + Anti-Slop + Craft Test, then apply the specific lens below.
Run a technical audit of the UI at the target the user described. Load the ui-craft skill and apply the audit lens.
Step 0: Visual capture (mandatory)
Code-only review is insufficient. Every audit/critique starts with the surface as the user sees it. Try the following in order; use the first one available:
1. Playwright MCP — if playwright MCP server is available, use it. Capture full-page screenshots at three viewports: desktop (1280×800), tablet (768×1024), mobile (375×812). Capture dark mode if the app supports it. 2. Browser DevTools / Chrome MCP — second choice; same viewport set. 3. Other browser automation (agent-browser, cursor-ide-browser) — third choice. 4. Ask the user — last resort. If no automation is available, request screenshots from the user before proceeding. Be specific:
- "Visual review needs screenshots. Please provide:
- Full-page at 1280px (desktop)
- Full-page at 768px (tablet)
- Full-page at 375px (mobile)
- Dark mode of each, if supported."
Do not begin the review until visuals are captured or provided. State this explicitly to the user when no automation succeeds — don't silently fall back to code-only review.
If the user declines to provide screenshots, run a code-only pass and clearly mark the report [CODE-ONLY REVIEW — visual issues not assessed] at the top so the limitation is explicit.
Note: audit is knob-agnostic — accessibility and performance are not tunable.
Scope (non-negotiable checks):
1. Accessibility — read references/accessibility.md:
- Visible
:focus-visibleon every interactive element - Keyboard reachable, no focus traps
- Touch targets ≥ 44px (mobile)
- Color not the only signal for state
- Form labels, error association, required indication
prefers-reduced-motionhonored for all animations
2. Performance — read references/motion.md Rendering Performance section:
- Only
transform/opacityanimated (nowidth/top/height) - No
transition: all will-changescoped to active interaction, removed after- Images have
width/heightoraspect-ratio(CLS) - No layout thrash in scroll/resize handlers
3. Responsive — read references/responsive.md:
- Mobile-first breakpoints, no fixed-width components
env(safe-area-inset-*)respected on fixed elements- Touch zones don't overlap
- No horizontal scroll at 320px
Output format — the Review Format table from SKILL.md:
| Before | After | Why |
|---|
Group findings by priority: Critical (blocks usability/a11y) → High-impact (immediately noticeable) → Quick wins (polish).
Do NOT rewrite code unless asked. Report findings first; wait for approval before editing.
Related skills
FAQ
Does the audit need screenshots?
Yes. Every audit starts with a mandatory visual capture at desktop, tablet, and mobile viewports via Playwright or a browser MCP; if none is available it asks the user for screenshots.
Does it rewrite my code?
No. It reports findings first and waits for approval before editing, and does not rewrite code unless asked.