Getting started
Three readers, three entry paths. Pick the one that fits how you'll consume the system. Each path lands you on the same underlying tokens, components, and patterns — what differs is which surfaces you'll touch first.
For designers
Figma file, token copy-on-click, the shape of the visual system. Start here if your output is mocks, screens, or specs.
For developers
Install, import, the consumer migration playbook. Start here if your output is code.
For agents
JSON manifest, schema, llms-design.txt, version pinning. Start here if you're an AI agent fetching the system as context.
What the system gives you
| Surface | Where it lives | What you do with it |
|---|---|---|
| Tokens | @matter/tokens (TS) + CSS variables | Read values; write through CSS vars, not literals |
| Components | @matter/components + @repo/brand | Import and compose; one page per export in Components |
| Patterns | apps/design/content/design/patterns/ | Read the composition recipe; copy structure, not pixels |
| Recipes | apps/design/content/design/recipes/ | Full-screen layouts paired with apps/app/ source links |
| Agent payload | /design-system.json + /llms-design.txt | Fetch once; pin to the version field |
What you don't do
- Don't fork visual primitives. When a component doesn't fit, propose an extension via Governance — never rebuild it in your own surface.
- Don't hardcode hex. Every color reads from a token. The drift gate fails CI on raw color literals in MDX, and the same rule applies to source.
- Don't compare Matter to other products in copy. Describe what Matter does plainly and self-contained. The authoring rules page is the canonical reference.
What's new
The latest release of @matter/tokens and @matter/components is reflected in /design-system.json at version 2.3.0. The changelog tracks what landed in each release; the governance page tracks how proposals become tokens and components.