ui-speclisted

# UI spec A mockup shows one state of one breakpoint with realistic data. An implementation needs every state at every breakpoint with hostile data. The gap between those two is where an unattended run starts inventing — and invented UI is the kind of wrong that survives review, because it looks finished. This skill closes the gap on paper, before any of it is built. ## 1 — Map to what already exists Never describe a component in the abstract when the workspace already has one. Run `pattern-mine` for the nearest existing component and specify by difference: "the standard `DataTable` from `libs/ui/table`, with a sticky first column and row selection". For every visual value in the design, resolve it to a **token**, not a literal: | In the design | In the spec | |---|---| | `#1B4B8F` | `--color-primary-700` | | 24px gap | `--space-6` | | that shade of grey text | `--color-text-muted` | A literal hex in a spec becomes a hardcoded hex in the code, which survives every theme change and every rebrand. When a design value has no matching token, that is a finding for the design system owner and a ledger entry — not a licence to hardcode. Say which token you chose as the nearest and by how much it differs. ## 2 — Write the state matrix For each component in the design, specify all of these. Where the design is silent, say so explicitly and name the fallback: - **Default, hover, focus-visible, active, disabled, read-only** — focus especially: designs omit it about as often as