agentleFS
KyaniteLabsKyaniteLabs/tastecheck/skills/empty-states/SKILL.md

empty-states

Skill12 starsChanged 11 days agoMITView on GitHub

Empty, loading, and error-state design. Use for first-run screens, zero results, empty lists/tables/dashboards, loading skeletons, offline/permission errors, retries, layout stability, and state copy.

5 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every reachable data state needs truthful treatment.

    line 11
  2. Distinctive:

    Use a layout-matching skeleton when final geometry is known and it aids orientation.

    line 38
  3. Very specific:

    Every empty state has heading, context, and safe next action.

    line 46
  4. Distinctive:

    Use plain, blameless language.

    line 52
  5. Very specific:

    Use references/patterns.md for state markup/copy.

    line 66
  6. Very specific:

    Stop / handoff: Stop when the cause of absence cannot be distinguished.

    line 99

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Empty States

Every reachable data state needs truthful treatment; absence and failure need different next moves.

Start with a state contract, not a set of illustrations

Name region and transition before copy/illustration. Record:

QuestionDecision to record
User goalWhat they came to find, create, compare, or finish in this region
Data authorityNetwork source, local draft, cached result, permission boundary, or user-entered filter
Entry conditionThe observable event that enters loading, zero-result, error, stale, or partial state
ContinuityWhat remains visible and editable while the state is active
RecoveryThe action that can change the state, its owner, and whether retry is safe to repeat
Exit proofThe event that replaces the state and the announcement/visual confirmation the user receives

First-use, zero results, and permission absence need different truth. Trusted cached data is stale content with progress, not a blank reset.

Model the reachable state set

Design loading when work can be in flight, empty when success can contain zero items, and error when the region can fail. Static/local regions need not invent states. Add stale, partial, awaiting-input, or pending-mutation only when their entry condition exists; never merge zero, unavailable, and loading.

Loading: communicate the wait honestly

Use a layout-matching skeleton when final geometry is known and it aids orientation. Use determinate progress when measurable, compact status for short waits, and a spinner only as a supporting cue. Delay transient indicators when measured latency makes flashing likely, but keep slow work visible. Never imply unknowable progress/shape. Use optimistic UI only when rollback and reconciliation are safe.

Empty: the three flavors, each with a next step

Every empty state has heading, context, and safe next action. First-run teaches; user-cleared affirms completion; no-results names query/filter and offers clear/broaden/correct/create. If no action exists, say what will fill it.

Error: explain, reassure, offer recovery

Use plain, blameless language; distinguish offline, permission, not-found, and server when recovery differs. Preserve work; offer retry, a working route, or support proportionate to the consequence.

Preserve continuity through transitions

Retain position, content, filters, and drafts unless safety/integrity forbids it. Make retry visible without duplicate mutation; explain rollback and return focus to repair. Record idempotent, confirmation-required, or support-only retry—never promise retry can resolve permission or duplicate-money risk. Give each request an owner; late responses must not replace current state.

Quick start

Use references/patterns.md for state markup/copy. Render one explicit state per region, reserve space, announce changes, and preserve work across errors.

Reference files

  • references/patterns.md — patterns, copy, skeletons, announcements.
  • references/decision-records.md — novel-case ADR rules.

Decision order and evidence

For each state, record cause, retained context, next action, retry semantics, exit proof, and accessible recovery; n/a requires subject absence. Hand control behavior to component-states.

Self-check

  1. Reachable loading, empty, and error states are distinct and truthful?
  2. Empty has heading/context/forward action; no-results has an exit?
  3. Errors explain/recover without raw internals; loading matches what is known?
  4. Changes announce, preserve work, reject stale responses, and state safe retry/cached/partial behavior?

Deliver

Deliver a region matrix: entry, message, retained context, recovery, exit, announcement, and layout-shift evidence. Keep containers stable; hand adjacent scope off.

<!-- contract:v1:start -->

Contract (generated)

Canonical detail: contract.json.

  • Route: A data region needs first-use, no-results, loading, permission, or error states.; avoid: The issue is only a button or field state.
  • Exclude: Do not use a spinner as the only loading communication. (+1 in contract.json)
  • Stop / handoff: Stop when the cause of absence cannot be distinguished. (+1 in contract.json); receives [component-states, data-viz, design-system-interview, deslop-ui, improve-existing-website, tasteroll] -> sends [component-states, a11y-pass, humanize-copy, tastecheck-pass, cognitive-a11y]
  • Output: domain-specific data-region state plan
  • Evidence: table_with_evidence with status, reason, remediation, evidence, provenance.
<!-- contract:v1:end -->

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.