# State Machine

Renders every state of a component you choose on a throwaway page, with mock data and a...

- Repository: https://github.com/jakubkrehel/skills (10031 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-25
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add jakubkrehel/skills --skill state-machine -g -a claude-code -y`
Codex: `npx skills add jakubkrehel/skills --skill state-machine -g -a codex -y`
Cursor: `npx skills add jakubkrehel/skills --skill state-machine -g -a cursor -y`
Gemini CLI: `npx skills add jakubkrehel/skills --skill state-machine -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add jakubkrehel/skills`

## Description

Renders every state of a component you choose on a throwaway page, with mock data and a switcher, so you can work on each state.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# State machine

This skill takes one component and renders it on a throwaway page in every state it can be in. Mock data feeds each state, a switcher flips between them and the page is deleted in one step when you are done.

It is a workbench, not a review. The page stays up while the user works on the visuals, one state on screen and every other a keypress away. Stacking hostile scenarios on one page for a single look is `break`, exploring alternative designs is `variant` and reviewing finished work is `interface-review`.

## 1. Scope one component

One component per run: the audit log table, the network panel, the billing card. "The settings page" spans several, so list them and ask which one.

Restate it in one sentence: what the component shows, where it renders in production and where its data comes from.

## 2. Find the states in the code

The states are the branches the component already has. Read it and its data hooks for every one:

| Kind | States |
| --- | --- |
| Data | Loading, empty, error, one item, a typical set, a set long enough to scroll or paginate, some requests resolved and others pending, stale data refetching |
| Account | Plan tier, role and permission checks, an owner versus a member |
| Feature | Flags, trials, limits reached, a disabled or locked feature |

A state the code cannot reach is not a state. Do not add a branch to render one. Where the design shows a state the code lacks, list it as missing and leave it out.

Write the set down before building, one line each, named the way the product talks about it: `empty`, `enterprise`, `member-no-access`. Group them under headings in the product's words, by what changes. Use `Data` and `Account` or narrower ones such as `Connection` or `Access`. The switcher shows these groups. Say which kinds you dropped and why in one line. Combine kinds only where the code branches on the combination, such as `member-empty`, never as a cross product.

## 3. Build the throwaway page

The rest: https://github.com/jakubkrehel/skills/blob/HEAD/skills/state-machine/SKILL.md