error-states

Designs error, empty, loading, and edge states for every flow after hi-fi design.

1|Updated Jun 30, 2026
One-click install
npx skills add https://github.com/Lia-Creative/lia-plugins --skill error-states-lia-creative
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: error-states
Source: https://github.com/Lia-Creative/lia-plugins/tree/main/lia-tools/skills/error-states
Command: npx skills add https://github.com/Lia-Creative/lia-plugins --skill error-states-lia-creative

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Happy-path-only designs leave builders inventing error, empty, loading, and edge states at midnight. This Skill runs a systematic four-pass sweep over every flow so each state is either designed or explicitly ruled out with a written reason. ## Core Features & Use Cases - Four-pass state sweep: For every flow, it checks error, empty, loading, and edge states using scenario Givens, flow transitions, and schema nullability as sources of truth. - Designed-or-ruled-out outcomes: Every state found gets exactly one of two outcomes — designed in the hi-fi artefact, or ruled out with a documented reason — so silence never becomes a builder's guess. - Handoff integration: The completed state list feeds the design-lead coverage verdict and the state class in the design-handoff artefact for builders. - Use Case: After finishing hi-fi screens for a checkout flow, run the sweep to catch the offline-mid-payment case, the empty cart first-run view, and the slow-inventory loading state before handoff. ## Quick Start Ask the agent to sweep the states for the current flow and design or rule out each error, empty, loading, and edge case.

Frequently Asked Questions about error-states

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design error states for a user flow?▼

Run a four-pass sweep per flow: check each transition that can fail for error states, first-run and zero-item cases for empty states, every wait for loading states, and awkward realities like offline or huge data for edge states. Each state must be designed or ruled out with a written reason.

What states should a design cover before developer handoff?▼

Cover error, empty, loading, and edge states for every flow. Sources of truth are scenario Givens that can be false, flow transitions that can fail, and schema fields that can be null, huge, or absent.

When should error state design happen in the design process?▼

After hi-fi design is complete, as a separate seat from the session that drew the happy path. The sweep runs before design-lead's coverage verdict and before design-handoff carries the artefact to the ticket.

Can I skip designing a state if it does not apply?▼

Yes, ruling a state out with a written reason is a first-class outcome, such as noting offline mid-upload is not designed because the product runs local-only. Silence is the only unacceptable outcome, since it leaves builders inventing.

What are the limitations of an error state sweep?▼

It does not create new flows — a missing flow discovered during the sweep routes back to flow design. It also does not QA the built product; verifying built states against the artefact happens later in polish.