ux-audit
Feature-level UX audit for React/Next.js code. Catches what Lighthouse, axe, ESLint, and Storybook miss — state coverage gaps (missing loading/empty/error), form data loss on validation, broken focus management, optimistic UI without rollback, skeleton-induced layout shift, vague microcopy, and 25+ other modern frontend UX bugs. Diff-aware (audits changed files only) and produces a 3-tier ship-readiness verdict (release-blocker / fix-this-sprint / backlog) grouped by surface, with concrete fixes using modern React 19 APIs (useActionState, useFormStatus, useOptimistic, useTransition, Suspense). Use before merging a frontend PR, before shipping a feature, or when asked "is this checkout/onboarding/dashboard ready?", "review this PR for UX bugs", "audit this component", "what would break in production?", "is this ready to ship?"
What this skill does
# UX Audit
Static UX-quality reviewer for React/Next.js code. Operates at the **feature level** (a checkout flow, an onboarding flow, a dashboard) — not the principle level. Answers one question for a frontend dev with a PR open: "**which of these will hurt users in production, and which are nice-to-haves?**"
## What this skill IS
- A diff-aware reviewer that audits changed files in a PR
- A feature-level checklist runner: detects "this is a sign-in flow" / "this is a checkout" / "this is a modal" and runs the right playbook
- A ship-readiness verdict generator: every finding gets `release-blocker | fix-this-sprint | backlog`
- A concrete-fix advisor that uses modern React 19 APIs (`useActionState`, `useFormStatus`, `useOptimistic`, `useTransition`, `<Suspense>`, error boundaries)
## What this skill IS NOT
Defer to the right tool. **Do not duplicate** what these already do well:
| Concern | Use this tool instead | Why |
|---|---|---|
| Core Web Vitals (LCP, CLS, INP) | Lighthouse + web-vitals + Vercel Agent | Field + lab measurement, not static |
| WCAG rule violations | axe-core / jsx-a11y | Authoritative rule list, structured violations |
| a11y prevention at write time | eslint-plugin-jsx-a11y | Lint catches before runtime |
| Visual regression | Chromatic / Percy | Pixel-level diffs |
| Bundle size budget | size-limit / bundle-analyzer | Continuous budget tracking |
| Generic bug review | CodeRabbit / Vercel Agent | LLM bug review of the whole diff |
When a finding overlaps any of the above, link out — don't restate.
See `references/defer-to-other-tools.md` for the full inventory.
## Audit Workflow
Copy and track this checklist:
```text
UX Audit progress:
- [ ] Step 1: Determine scope (PR diff via `git diff --name-only main` OR explicit file/folder)
- [ ] Step 2: Detect features in scope (sign-in / checkout / form / modal / list / dashboard / etc.)
- [ ] Step 3: For each feature, run its playbook from references/feature-playbooks.md
- [ ] Step 4: For each check, load the matching rule (rules-modern/ for state/form/focus bugs; rules/ for Laws of UX)
- [ ] Step 5: Assign each finding a ship tier per references/ship-readiness.md
- [ ] Step 6: Group findings by surface, render with the chosen output adapter
- [ ] Step 7: Verify the audit-self-check before reporting
```
1. **Scope.** Default to `git diff --name-only main` if in a git repo with uncommitted changes; otherwise audit the explicit scope the user passes. Don't audit the whole codebase by default — noise floor is too high.
2. **Detect features.** Match on element semantics + filenames + route paths. A `<form>` with email + password = sign-in. A `<form>` with a multi-step indicator = onboarding. A `role="dialog"` = modal. See `references/feature-playbooks.md` for detection heuristics per feature.
3. **Run playbook.** Each feature has 5-7 ordered checks. Don't skip checks even when you expect them to pass; each pass goes into the audit-self-check.
4. **Load rules.** Two layers:
- **`rules-modern/`** (Layer 2) — modern frontend UX failure modes (state coverage, form preservation, focus mgmt, optimistic rollback, CLS, microcopy). This is where most findings come from.
- **`rules/`** (Layer 3) — Laws of UX (Hick's, Fitts's, Miller's, etc.). Used for cognitive/perceptual reasoning when Layer 2 doesn't apply.
5. **Ship tier.** Every finding gets one of three tiers (see `references/ship-readiness.md`):
- `release-blocker` — fix before merge (data loss, broken auth, missing critical-path error state, dark patterns, focus traps that don't restore)
- `fix-this-sprint` — merge but log issue (sub-44 px target on touch, missing skeleton, vague error, missing empty CTA)
- `backlog` — track, ship (dark-mode untested, RTL not verified, microcopy nits)
6. **Group + render.** Group by surface (component file or page). Render with one of the three adapters in `references/output-adapters.md`.
7. **Self-check.** Verify the audit was actually run (rules executed > rules planned, file:line cited on every finding, fix snippet on every finding).
## Three audit layers
```
Layer 1 — Feature playbooks (the entry point)
references/feature-playbooks.md
12 features × 5-7 ordered checks → pulls rules from Layers 2 and 3
Layer 2 — Modern frontend failure modes (the high-leverage layer)
rules-modern/<category>-<slug>.md
33 rules covering state coverage, form preservation, focus mgmt,
async/optimistic, CLS pairings, microcopy, dark mode, i18n, mobile.
Detection recipes use React 19 APIs.
Layer 3 — Laws of UX (the cognitive/perceptual reserve)
rules/<prefix>-<slug>.md
30 rules for Hick's, Fitts's, Miller's, etc. Invoked when feature
playbooks need cognitive load / decision / perception reasoning.
Usually 1-2 of these per audit; not all 30.
```
## Diff-aware mode
Default scope is the PR diff. Detect with:
```bash
git diff --name-only main -- '*.tsx' '*.jsx' '*.ts' '*.js' '*.css' '*.module.css'
```
Audit only those files. Surface the base branch in the output: `Auditing: 8 files changed vs main`.
For a quick local check (single component): `git diff --name-only HEAD -- src/Component.tsx`.
For a full sweep: explicit `--full src/` (rare; only when introducing the skill to a codebase).
## Ship-readiness verdict
Every audit emits a top-level verdict before per-finding details:
```text
═══════════════════════════════════════════════════════════
SHIP VERDICT: ❌ NOT READY (1 release-blocker)
Surface count: 3 (CheckoutForm, PaymentStep, ConfirmStep)
Findings: 7
Release blockers: 1 ⛔ Form data loss on validation (PaymentStep.tsx:42)
Fix this sprint: 3 ⚠️
Backlog: 3 📋
Defer-to (not audited here):
Performance (CWV): Run Lighthouse
Bundle size: Run size-limit
WCAG violations: Run axe-core
═══════════════════════════════════════════════════════════
```
Verdict tiers:
- ✅ **READY** — 0 release-blockers, ≤3 fix-this-sprint
- ⚠️ **READY WITH FOLLOW-UP** — 0 release-blockers, ≥4 fix-this-sprint
- ❌ **NOT READY** — ≥1 release-blocker
- 🚫 **INCOMPLETE** — audit-self-check failed (re-run)
## Output adapters
Three formats, all rendered from the same JSON. Pick based on context.
| Adapter | When | Format |
|---|---|---|
| Terminal table | Local dev, fast scan | Tight 5-col table grouped by surface |
| PR comment | GitHub / Vercel review | Markdown with `suggestion` blocks for inline diffs |
| CI JSON | Pipelines, dashboards | Strict JSON per `references/output-schema.md` |
See `references/output-adapters.md` for verbatim templates and field mappings.
## Skip protocol
A finding can be intentionally suppressed with an inline comment:
```tsx
{/* ux-audit-ignore:focus-not-restored — intentional: parent owns focus */}
<Dialog open={open} onClose={onClose}>
```
Slug must match the rule slug. Suppressions are reported in the audit summary so reviewers can verify intent.
## Reference Files
| File | Read when |
|------|-----------|
| `references/feature-playbooks.md` | Step 2-3 — detecting features and selecting their playbooks |
| `references/modern-failure-modes.md` | Index of all 33 modern rules grouped by category |
| `references/states-coverage.md` | Validating loading/empty/error/disabled coverage per component type |
| `references/ship-readiness.md` | Step 5 — assigning each finding a ship tier with examples |
| `references/output-adapters.md` | Step 6 — formatting findings for terminal / PR comment / JSON |
| `references/defer-to-other-tools.md` | Recognizing concerns to delegate (CWV, WCAG, bundle, etc.) |
| `references/output-schema.md` | Strict JSON schema for findings + verdict |
| `references/observational-rubrics.md` | Layer 3 rubric rules (1-5 scoring with anchors) |
| `rules-modern/<category>-<slug>.md` | Step 4 — running a Layer 2 modern frontend check |
| `rules-modern/_sections.md` | Category index for the modern rule layer |
| `rules/<prefix>-<slug>.md` | Step 4 — running aRelated in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.