agentleFS
MaxPrehodaMaxPrehoda/motif/skills/empty-states/SKILL.md

empty-states

Skill1 starsChanged 43 days agoMITView on GitHub

Finds lists, tables, search results and dashboards that show nothing, or just a bare line of text, when there's no data. Works out why each one would be empty, then builds an empty state with a short explanation and one action. Use after the design-system pipeline, or when an app looks broken before it has any data.

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

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use existing components: the same buttons, font sizes and spacing as the rest of the app.

    line 55
  2. Very specific:

    If there are three or more, make one shared <EmptyState> component that takes an icon, title, description and action.

    line 63

“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

Find places that show nothing when there's no data, and give each one a proper empty state.

Step 1: Find them

# loops over data
grep -rn -E '\{#each|\.map\(|v-for=' src --include="*.svelte" --include="*.tsx" --include="*.vue" | head -40

# bare "no items" text
grep -rn -iE '"(no |empty|nothing |none )' src --include="*.svelte" --include="*.tsx" | head -30

# checks for an empty list
grep -rn -E '\.length\s*===?\s*0|\.length\s*<\s*1|!\w+\.length' src --include="*.svelte" --include="*.tsx" | head -30

Sort what you find into three groups:

  1. Nothing at all. Shows an empty box. The user can't tell it apart from something that failed to load.
  2. Bare text. Something like <p>No items</p>. It says it's empty, but not why or what to do next.
  3. Already done. Has an icon, an explanation and an action. Leave these alone.

Fix the ones most people see first. The list a new user sees right after signing up comes before a filtered admin screen.

Step 2: Work out why it's empty

Why it's empty decides what it should say. The wrong message contradicts what the user just did.

TypeWhy it's emptyWhat to show
First useNew account, nothing created yetWhat the feature does, and a button to create the first item
ClearedThe user finished or deleted everythingAcknowledge it. Don't explain the feature again
No resultsA search or filter matched nothingRepeat what they searched for, and offer to clear it
Error or no accessThe request failed, or they don't have permissionWhat happened, and how to fix it

For example, showing a "get started" message to someone who just cleared their list makes it look like the product forgot what they did.

Step 3: Build it

Four parts, in this order:

  1. Icon. 32 to 48px, in text-muted-foreground, from the project's icon library.
  2. Headline. Say what's missing, in a neutral way. "No projects yet", not "Empty".
  3. Explanation. One line on what this feature does. Skip it for cleared states.
  4. Action. One button that fixes the situation. For no results, that's clearing the search or filter, not creating something new.

Rules:

  • Use existing components: the same buttons, font sizes and spacing as the rest of the app.
  • Center it vertically, and keep the text narrow with max-w-sm.
  • Only one action.
  • Describe problems as facts, not as the user's fault. "No results for 'xyz'", not "You didn't find anything".
  • While data is loading, show a loading skeleton. Only show the empty state once the data has come back empty. Showing it while a request is still running tells the user something that isn't true.

Step 4: Make a shared component if it repeats

If there are three or more, make one shared <EmptyState> component that takes an icon, title, description and action. With fewer than three, keep them inline.

Report

For each empty state: the file, its type, and what it showed before. List the components you used and confirm none of them are new. Point out any message that needs the product's own voice instead of placeholder wording.

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.