aesthetic

name	aesthetic
description	Use when an agent needs to adopt, verify, or generate Misty Step UI with Aesthetic: tokens, recipes, static registry, design law, page/specimen routes, or rendered-interface checks. Trigger phrases: "Aesthetic", "Misty Step design system", "design law", "tokens", "recipes", "law gate".
argument-hint	[adopt|audit|tokens|recipes|law|registry]

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.