Command
/unhappy
State-first design pass — inventories and implements all non-happy states (loading, empty, error, partial, conflict, offline) before the happy path, and refactors impossible boolean state to proper state machines. Use when starting a new screen, reviewing an existing one for
One command from ui-craft.
shell
$ npx -y skills add educlopez/ui-craft --agent claude-codeShips with ui-craft. Installing the plugin gets this command.
How it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/unhappy
Context preview
What this command does when you run it.
State-first design pass — inventories and implements all non-happy states (loading, empty, error, partial, conflict, offline) before the happy path, and refactors impossible boolean state to proper state machines. Use when starting a new screen, reviewing an existing one for
Stats
Stars209
Forks9
LanguageGo
LicenseMIT
Ships with ui-craft
Command definition
unhappy.md
--- description: State-first design pass — inventories and implements all non-happy states (loading, empty, error, partial, conflict, offline) before the happy path, and refactors impossible boolean state to proper state machines. Use when starting a new screen, reviewing an existing one for edge-case gaps, or when the user says "handle the error state" / "add loading states" / "what happens when data is missing". argument-hint: "[file or component path]" --- Design every non-happy state for the UI at `$ARGUMENTS`. Load the `ui-craft` skill and read `references/state-design.md`. **Step 1 — Inventory.** List every data source and interactive surface in the target. For each, enumerate its states: | Surface | idle | loading | empty | error | partial | conflict | offline | |---------|------|---------|-------|-------|---------|----------|---------| Mark each cell as **designed** (exists in code), **missing** (must add), or **N/A** (not applicable — e.g., a read-only view has no conflict state). **Step 2 — Fill the missing states.** For each missing state, either stub it inline or add a follow-up task comment. Use `references/state-design.md` for: - Skeleton sizing (match final layout, 200ms delay, 5s upper bound) - Empty-state copy (why empty + next action + visual) - Error-state contract (specific cause + one-click recovery + support ID) - Offline handling (queue writes + reconcile on reconnect) **Step 3 — Audit the happy path.** Flag every spot where the happy path assumes resource presence without checking. Fix with early-returns, state guards, or discriminated-union state handling. Booleans like `isLoading && !error && data` that allow impossible states are findings — refactor to a proper state machine or reducer.
