Error states
Design the non-happy-path UI in Next.js — loading, error, not-found, and empty states with Suspense, error boundaries, and user-facing feedback. Use when a page fetches data, can fail, or can be empty.From its SKILL.md
npx -y skills add m-binimran/dev-pack --skill error-statesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.5 KB, 312 tokens by cl100k_base, as published. Nobody here has run it
error-states
Most apps ship the happy path and forget the other three. A surface isn't done until loading, empty, and error are all handled.
The four states for every data surface
- Loading —
loading.tsxor<Suspense fallback>. Use skeletons that match the final layout (no CLS), not a bare spinner where possible. - Empty — designed empty state with a next action ("No projects yet — create one"), not a blank box.
- Error —
error.tsx(client error boundary) with a human message + a retry (reset()); log the real error server-side. Never show a raw stack trace to users. - Not found —
not-found.tsx+notFound()for missing resources (real 404, not a 200 with "nothing here").
Feedback for actions
- Mutations show pending state (disabled + spinner) and a success/error toast (
aria-livefor errors). - Optimistic updates roll back visibly on failure (see
state-architect).
Output
- The loading/empty/error/not-found treatments for the surface, and the action feedback.
- State which of the four are implemented and which are N/A.
Guardrails
- No surface ships with only the happy path.
- Error UI must not leak internal details; log them server-side instead.
- Skeletons must reserve the real layout's space to avoid layout shift.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.