uilintlisted

Catch the UI states and failure paths that get skipped — loading, empty, error, success, and partial. Use whenever building or reviewing an interface that fetches data, submits a form, or navigates, and whenever a user describes an interface problem in symptoms rather than terms — "nothing happens when I click", "it just spins forever", "the page goes blank", "users don't know if it worked", "this form is annoying", "why does this feel broken", "review this component", "/uilint". Also use proactively while writing UI, so the states exist in the first draft instead of being retrofitted after someone complains.
DahanItamar/uilint · ★ 0 · Code & Development · score 72

Install: claude install-skill DahanItamar/uilint

# uilint Interfaces get built along the path where everything works. The person building it clicks the buttons in the order that succeeds; the states for slow networks, empty accounts, and failed requests never get written, because nobody asked for them. Your job is to notice what is missing before the user does. **This skill covers behaviour, not appearance.** Spacing, colour, typography, elevation and motion belong to the `craft` skill — do not comment on them here. Contrast, ARIA and screen-reader semantics belong to `accessibility`. Name those skills once if clearly relevant, then move on. ## The five states Every section that fetches, submits, or navigates needs all five considered. Most code has one. | State | The question it answers | | --- | --- | | **Loading** | Is something happening, and is it worth waiting for? | | **Empty** | There is nothing here — is that broken, or just new? | | **Error** | It failed. What failed, why, and what do I do now? | | **Success** | Did it actually work? | | **Partial** | Half of it loaded. Is the rest of the page still usable? | "Considered" is not "present". A list that can never be empty needs no empty state — but that has to be a decision, not an oversight. ## Two modes **Build mode** — you are writing or editing UI. Apply the rules as you write, not afterwards. Before reporting the work complete, walk the five states against what you just wrote. If a `required` rule is unmet, the component is not finished: say so, name