Aesthetic
Aesthetic is the Misty Step design system: one CSS artifact, token contract, recipes, static registry, and law gate. Use it before inventing one-off UI vocabulary for Misty Step-facing products, docs, dashboards, artifacts, or internal tools.
Read DESIGN.md before visual work. Read docs/ADOPTING.md before adding
Aesthetic to another repo.
Route
| Need | Surface |
|---|---|
| Install or upgrade the package | @misty-step/aesthetic pinned by version or git tag |
| Understand invariants vs consumer dials | docs/ADOPTING.md |
| Generate visuals that feel like Misty Step | DESIGN.md |
| Use tokens programmatically | tokens.json |
| Use behavior snippets | recipes/ and recipes/recipes.js |
| Read machine-facing registry data | site/r/*.json |
| Verify rendered law compliance | npm run ci |
Operating Rules
- Aesthetic owns the vocabulary. Do not add a second design system beside it.
- Raw colors, radii, type scales, shadows, and motion curves need a named reason when a repo already consumes Aesthetic.
- Rendered output is the proof surface. Passing source lint is not enough when a page, artifact, or dashboard can be opened.
- Keep consumer steering in the consumer repo. Aesthetic provides invariants and dials; products choose brand accents and local layout needs.
- Do not copy prototype files into production. Rebuild the locked direction with package tokens, recipes, and registry references.
Verification
In the Aesthetic repo:
npm run ci
For consumer repos, run that repo's native gate plus the rendered law or visual check it has adopted. If no gate exists, that is the integration gap to fix.