| name | ui-rules |
| description | Use when defining how a product's UI looks and behaves — layout, cards, buttons, badges, typography — so every page feels like one product instead of the agent inventing a new style each session. |
ui-rules
Overview
ui-tokens are the primitives; ui-rules is how they combine. This is your design system in prose — the behavior and look of components — so every page belongs to the same product even with no Figma file.
Lives at context/ui-rules.md.
When to use
- After
ui-tokens, when defining the look/feel.
- When pages are starting to feel like different products.
What goes in it
- Typography usage — which scale for headings/body/labels.
- Layout — page structure, max-widths, grid, spacing rhythm.
- Components — how cards, buttons (variants), inputs, badges, etc. should look and behave.
- States — hover/focus/disabled/loading/empty conventions.
- Density + tone — compact vs roomy, sharp vs soft.
How to build it
Write the visual rules once. If you have a Figma design, feed it through a Figma MCP (or to the agent) and have it generate this file.
How to maintain
Update when a pattern changes; new concrete components get captured in ui-registry (via imprint), not here. ui-rules = the principles; ui-registry = the instances.
Common mistakes
- Mixing rules and instances → keep principles here, built components in
ui-registry.
- Rules too vague to follow → "buttons are rounded" beats "buttons look nice." Reference tokens.
