/ux-states-audit
Audit UI code for missing loading states, empty states, and error states. Every async operation and data-driven UI must handle all three. Finds gaps and implements the missing states using the app's existing patterns.
$ npx -y skills add markmdev/meridian --skill ux-states-audit --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ux-states-audit
Context preview
The summary Claude sees to decide when to auto-load this skill.
Audit UI code for missing loading states, empty states, and error states. Every async operation and data-driven UI must handle all three. Finds gaps and implements the missing states using the app's existing patterns.
SKILL.md
ux-states-audit.SKILL.mdname: ux-states-audit
description: Audit UI code for missing loading states, empty states, and error states. Every async operation and data-driven UI must handle all three. Finds gaps and implements the missing states using the app's existing patterns.
UX States Audit
Every piece of UI that fetches data or triggers async work has three states beyond the happy path: **loading**, **empty**, and **error**. LLMs implement the happy path and leave the rest blank. This skill finds and fills those gaps.
This is distinct from error-audit: error-audit finds errors that are *suppressed*. This finds states that were *never implemented*.
Step 0: Understand existing patterns
Before touching anything, read the codebase to understand how it currently handles these states:
- What components or primitives exist for loading (skeletons, spinners, shimmer)?
- What does an empty state look like — is there a shared component, or inline?
- How are errors shown to users — toast, inline message, error boundary?
Use these patterns exclusively. Don't introduce a new loading spinner if one already exists.
What to look for
**Missing loading state:**
- Data fetch starts, nothing changes in the UI until data arrives
- Button triggered action with no pending/disabled state
- Form submission with no in-progress indicator
- Navigation or route transition with no feedback
**Missing empty state:**
- List or table that renders nothing (blank space) when data is an empty array
- Search results that show nothing without explanation
- Dashboard widgets that disappear when there's no data instead of explaining why
**Missing error state:**
- Fetch fails → component renders identical to loading or blank
- Form submission fails → nothing visible changes
- Mutation errors that are caught in the data layer but never reach the UI
Process
1. Identify the scope from the user's request 2. Find every component that fetches data or triggers async work 3. For each: check whether loading, empty, and error states are handled 4. Implement missing states using the patterns found in Step 0 5. Report what was added, by component
Fix principles
- Loading states should be immediate — shown before the first byte arrives
- Empty states should explain the situation and, where appropriate, offer an action ("No results — try a different search")
- Error states should say what went wrong and what the user can do (retry, go back, contact support)
- Don't invent new UI primitives — use what already exists in the codebase
Reference files
- `references/ux-patterns.md` — Framework-specific patterns for missing loading, empty, and error states. Detection patterns, bad/fix examples. Read before starting the audit.
Report
Summarize by component: which states were missing, what was added.
Read more
name: ux-states-audit description: Audit UI code for missing loading states, empty states, and error states. Every async operation and data-driven UI must handle all three. Finds gaps and implements the missing states using the app's existing patterns.
UX States Audit
Every piece of UI that fetches data or triggers async work has three states beyond the happy path: **loading**, **empty**, and **error**. LLMs implement the happy path and leave the rest blank. This skill finds and fills those gaps.
This is distinct from error-audit: error-audit finds errors that are *suppressed*. This finds states that were *never implemented*.
Step 0: Understand existing patterns
Before touching anything, read the codebase to understand how it currently handles these states:
- What components or primitives exist for loading (skeletons, spinners, shimmer)?
- What does an empty state look like — is there a shared component, or inline?
- How are errors shown to users — toast, inline message, error boundary?
Use these patterns exclusively. Don't introduce a new loading spinner if one already exists.
What to look for
**Missing loading state:**
- Data fetch starts, nothing changes in the UI until data arrives
- Button triggered action with no pending/disabled state
- Form submission with no in-progress indicator
- Navigation or route transition with no feedback
**Missing empty state:**
- List or table that renders nothing (blank space) when data is an empty array
- Search results that show nothing without explanation
- Dashboard widgets that disappear when there's no data instead of explaining why
**Missing error state:**
- Fetch fails → component renders identical to loading or blank
- Form submission fails → nothing visible changes
- Mutation errors that are caught in the data layer but never reach the UI
Process
1. Identify the scope from the user's request 2. Find every component that fetches data or triggers async work 3. For each: check whether loading, empty, and error states are handled 4. Implement missing states using the patterns found in Step 0 5. Report what was added, by component
Fix principles
- Loading states should be immediate — shown before the first byte arrives
- Empty states should explain the situation and, where appropriate, offer an action ("No results — try a different search")
- Error states should say what went wrong and what the user can do (retry, go back, contact support)
- Don't invent new UI primitives — use what already exists in the codebase
Reference files
- `references/ux-patterns.md` — Framework-specific patterns for missing loading, empty, and error states. Detection patterns, bad/fix examples. Read before starting the audit.
Report
Summarize by component: which states were missing, what was added.
Meridian makes Claude Code more reliable on real projects. It adds persistent project context, smarter session handoff, and lightweight workflow enforcement so Claude is less likely to lose the plot halfway through a long task.
Other skills on meridian.
- /add-frontmatter
Scan all .md files in the project and add or fix YAML frontmatter (summary + read_when) so they can be discovered by context routers like Reflex.
Open skill - /create-docs
Create or update .meridian/docs/ knowledge files for a module or directory. Produces reference docs with frontmatter for context routing.
Open skill - /error-audit
Audit code for silent error swallowing, fallbacks to degraded alternatives, backwards compatibility shims, and UI that fails to show errors to the user. Finds and fixes all occurrences in the specified scope.
Open skill - /observability-audit
Audit code for observability gaps — debug logs left in, errors caught without being logged, missing context on log entries, untracked slow operations. Uses the app's existing observability tooling exclusively.
Open skill - /planning
Interview-driven planning methodology that produces implementation-ready plans. Always use this skill INSTEAD of EnterPlanMode — it provides structured interviewing (20-40 clarifying questions), exhaustive parallel codebase exploration (5-15 Explore agents), verbatim
Open skill

