Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →educlopez/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.
Passed 7 of 12 test cases with the skill, and 7 of 12 without it.
and 3 more in the full report
5 fixed7 passed either way5 still failing5 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
Review `src/components/NotificationCenter.tsx` for state coverage. No CRAFT_LEVEL variable is defined in the environment. Which required states must be stubbed by default?
| Checked | Without skill | With skill |
|---|---|---|
| The analysis defaults CRAFT_LEVEL to 7 when unspecified. | Missed | Passed |
| The required states stubbed for default CRAFT_LEVEL 7 include idle, loading, empty, error, and success. | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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:
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.
Step 4 — Optimistic UI + reconciliation. For offline-likely actions (saves, sends, edits, toggles), implement optimistic UI with reconciliation on reconnect. Queue writes locally. Surface any rejected writes — never swallow them.
Knob gating (CRAFT_LEVEL):
| CRAFT_LEVEL | Required states to stub |
|---|---|
| ≤ 4 | idle, loading, error |
| 5-7 | idle, loading, empty, error, success |
| 8+ | all six — add partial, conflict, offline |
If CRAFT_LEVEL is unknown, default to 7.
Convergence note: To iterate until all required states are present, load skills/ui-craft/references/loops.md and run preset state-coverage (budget = the default loop budget defined in loops.md): after stubbing the highest-priority missing required state, re-inventory until all knob-required states are present or budget exhausted. Emit the pre-flight cost notice before iteration 1.
Output: edit the code directly. After each file, print the Review Format table from SKILL.md:
| Before | After | Why |
|---|---|---|
no loading state on <ProjectList> | skeleton rows matching final layout, 200ms delay | prevents "is it broken?" perception; avoids CLS |
test cases passed, vs 7 / 12 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.