@motion-proto/live-tokens 0.72.0 → 0.73.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -3,73 +3,36 @@ name: live-tokens-fix-findings
3
3
  description: Bring an existing @motion-proto/live-tokens project into line with its design system by running check-page and check-component, reading the findings, and fixing each by rule until both exit 0. Use when the user asks to make the build pass, fix the design-system errors or warnings, clean up the literals, replace hex or pixel values with tokens, make a page or component themeable, or apply what a check reported. Not for the check itself (live-tokens-check-compliance reports and edits nothing), not for building a new page (live-tokens-build-page) or a new component (live-tokens-create-component), which run the same gate as their last step, and not for a single token edit (use the editor).
4
4
  ---
5
5
 
6
- # Fixing what the checkers report
7
-
8
- Two checkers hold a project to its design system. `check-page` holds pages:
9
- every component comes from the catalogue and is passed only the props it
10
- declares, and every value in page CSS is a theme token. `check-component`
11
- holds authored components: every token names a semantic property and its
12
- default is the theme token that property reads. A page or component that
13
- passes repaints when the theme changes. One that does not has opted out of the
14
- system silently, and these findings are where.
15
-
16
- This skill is the loop for code that already exists. Run the checker, fix one
17
- rule at a time, run it again, and stop only when both exit 0. When the user has
18
- not seen the state of the project yet, `npx live-tokens report --json` is the
19
- reading to start from, and **live-tokens-check-compliance** is the skill that
20
- presents it without editing; this one edits.
21
-
22
- ## Reach the checkers
23
-
24
- ```sh
25
- npx live-tokens check-page --json # every page under src/
26
- npx live-tokens check-component --json # every component authored under src/system/components
27
- ```
28
-
29
- - **Unknown command.** The installed package predates the checkers. Upgrade
30
- `@motion-proto/live-tokens`, then run `npx live-tokens migrate --check` and
31
- apply what it plans with `--write`; `--tokens <path>` names a tokens.css that
32
- sits somewhere other than the four default locations.
33
- - **No `check:design` script.** A project scaffolded by `create` has one. Add
34
- it to any other project's `package.json`:
35
- `"check:design": "live-tokens check-page && live-tokens check-component"`.
36
- Once it passes, gate the build: `"build": "npm run check:design && vite build"`.
37
- - **A file, not the project.** `check-page src/pages/Home.svelte` and
38
- `check-component <id>` scope a run when the user names one thing.
39
-
40
- ## The loop
41
-
42
- 1. Run with `--json`. Each finding carries a stable `rule`, a file, and a line.
43
- 2. Group by rule. Take errors before warnings, and the rule with the most
44
- findings first, because one recipe clears the whole group.
45
- 3. Apply that rule's recipe, below, to every finding in the group.
46
- 4. Run again. New findings can appear as old ones clear: a token you reached
47
- for may not exist, or a moved import may land somewhere the rule now sees.
48
- 5. Stop at exit 0. Then run once with `--strict` and report what it adds, so
49
- the user can decide whether warnings are worth clearing now.
50
-
51
- Three things the loop never does:
52
-
53
- - **Silence a rule to pass.** `--off=<rule>` is for a single run while
54
- working. A severity the project wants changed goes in
55
- `live-tokens.config.json` under `"checks": { "rules": { "<rule>": "warn" } }`,
56
- with the reason in the commit, and only when the user has made that call.
57
- - **Mint a token.** A literal with no token behind it is remapped to the
58
- nearest existing token by role. No new `--surface-*`, `--text-*`, or
59
- `--space-*` is added to `tokens.css` to match a value the page happened to
60
- use. If nothing fits, say so and leave the finding.
61
- - **Change what the page looks like without saying so.** Most remaps land on
62
- the same value. When the nearest token differs, `14px` to `--space-16` or a
63
- 55% black to `--scrim`, name the shift in the report.
6
+ # Fixing the checkers' findings
7
+
8
+ Two checkers hold a project to its design system. `check-page` holds pages: every component comes from the catalogue and is passed only the props it declares, and every value in page CSS is a theme token. `check-component` holds authored components: every token names a semantic property and its default is the theme token that property reads. A page or component that passes repaints when the theme changes. One that fails has opted out of the system silently, and its findings say where.
9
+
10
+ This skill is the loop for code that already exists. When the user has not seen the state of the project yet, **live-tokens-check-compliance** presents `npx live-tokens report` without editing; this skill edits.
11
+
12
+ ## Workflow
13
+
14
+ 1. Run both checkers with `--json`. Each finding carries a stable `rule`, a file, and a line.
15
+ ```sh
16
+ npx live-tokens check-page --json # every page under src/
17
+ npx live-tokens check-component --json # every component authored under src/system/components
18
+ ```
19
+ `check-page src/pages/Home.svelte` and `check-component <id>` scope a run when the user names one thing. Unknown command means the installed package predates the checkers: upgrade `@motion-proto/live-tokens`, then run `npx live-tokens migrate --check` and apply what it plans with `--write` (`--tokens <path>` for a tokens.css outside the four default locations).
20
+ 2. Group by rule. Take errors before warnings, and the rule with the most findings first, because one recipe clears the whole group.
21
+ 3. Apply that rule's recipe to every finding in the group: colour by role, geometry by scale, or the row in the table below. A component outside the catalogue hands off to **live-tokens-pick-component** for the shipped one that fits, or to **live-tokens-create-component**.
22
+ 4. Run again. New findings can appear as old ones clear: a token you reached for may not exist, or a moved import may land where a rule now sees it. Stop at exit 0.
23
+ 5. Run once with `--strict` and report what it adds, so the user can decide whether warnings are worth clearing now. Then report by rule.
24
+
25
+ A project scaffolded by `create` has a `check:design` script. Give any other project one in `package.json`, `"check:design": "live-tokens check-page && live-tokens check-component"`, and once it passes, gate the build: `"build": "npm run check:design && vite build"`.
26
+
27
+ ## Three things the loop never does
28
+
29
+ - **Silence a rule to pass.** `--off=<rule>` is for a single run while working. A severity the project wants changed goes in `live-tokens.config.json` under `"checks": { "rules": { "<rule>": "warn" } }`, with the reason in the commit, and only when the user has made that call.
30
+ - **Mint a token.** A literal with no token behind it is remapped to the nearest existing token by role. No new `--surface-*`, `--text-*`, or `--space-*` is added to `tokens.css` to match a value the page happened to use. If nothing fits, say so and leave the finding.
31
+ - **Change what the page looks like without saying so.** Most remaps land on the same value. When the nearest token differs, `14px` to `--space-16` or a 55% black to `--scrim`, name the shift in the report.
64
32
 
65
33
  ## Colour by role, never by hue
66
34
 
67
- `color-literal` is the finding that takes judgement. The replacement is the
68
- token for what the colour *does*, not the token that happens to be closest in
69
- hue, because the theme will move every role together and the page must move
70
- with it. `npx live-tokens tokens --family surface` prints a family's names and
71
- values (`text`, `border`, `scrim`, `tint` likewise; `--json` for data); the
72
- families are fixed.
35
+ `color-literal` is the finding that takes judgement. The replacement is the token for what the colour *does*, not the token nearest in hue, because the theme moves every role together and the page must move with it. `npx live-tokens tokens --family surface` prints a family's names and values (`text`, `border`, `scrim`, `tint` likewise; `--json` for data); the families are fixed.
73
36
 
74
37
  | The literal is | Token family | Notes |
75
38
  | --- | --- | --- |
@@ -82,15 +45,11 @@ families are fixed.
82
45
  | Fully transparent | `--color-transparent` | Never `transparent` inside a component default. |
83
46
  | A gradient | `--gradient-*` | Or compose one from surface tokens. |
84
47
 
85
- A `var(--x, #fff)` fallback is not a finding. A named colour is: `white` and
86
- `rebeccapurple` are literals like any hex.
48
+ A `var(--x, #fff)` fallback is not a finding. A named colour is: `white` and `rebeccapurple` are literals like any hex.
87
49
 
88
50
  ## Geometry by scale
89
51
 
90
- `dimension-literal` fires only on the geometry the theme owns: padding,
91
- margin, gap, border and outline widths, inset offsets, radius, and shadow.
92
- Sizing (a hero's height, a max content width, a `minmax()` floor) is layout
93
- and is never reported, so leave it.
52
+ `dimension-literal` fires only on the geometry the theme owns: padding, margin, gap, border and outline widths, inset offsets, radius, and shadow. Sizing (a hero's height, a max content width, a `minmax()` floor) is layout and is never reported, so leave it.
94
53
 
95
54
  | The literal is | Token | Notes |
96
55
  | --- | --- | --- |
@@ -100,8 +59,7 @@ and is never reported, so leave it.
100
59
  | A shadow | `--shadow-sm` through `-xl` | Replace the whole value, never one offset. |
101
60
  | Part of a `calc()` | The token inside the calc | `calc(var(--space-64) * -2 + var(--space-8))` |
102
61
 
103
- While in the file, motion values take `--duration-*` and `--ease-*` even
104
- though no rule reports them, and a `blur()` takes `--blur-*`.
62
+ While in the file, motion values take `--duration-*` and `--ease-*` even though no rule reports them, and a `blur()` takes `--blur-*`.
105
63
 
106
64
  ## Every other rule
107
65
 
@@ -120,17 +78,12 @@ though no rule reports them, and a `blur()` takes `--blur-*`.
120
78
  | `unknown-suffix`, `state-after-property`, `disabled-is-terminal` | Rename the token. Borrow the name a shipped component uses for the same role; the vocabulary and the state model are in **live-tokens-create-component**. |
121
79
  | `color-literal`, `unknown-token-ref`, `default-not-token` (component) | The `:global(:root)` default reads a theme token, composed if needed. A structural keyword (`start`, `contain`) is declared in the editor's `intrinsics`. |
122
80
  | `phantom-editor-token`, `phantom-link` | The editor names a token the runtime never declares, or a bare font helper spans slots. Both are editor fixes; see the same skill. |
123
- | `missing-registration`, `missing-file`, `missing-root-block` | The component is not wired the way the recipe in **live-tokens-create-component** wires it. |
81
+ | `invalid-id`, `missing-file`, `missing-root-block`, `no-tokens`, `missing-component-const`, `missing-all-tokens`, `missing-registration` | The component is not wired the way the recipe in **live-tokens-create-component** wires it: a lowercase id, a runtime file with a `:global(:root)` block, an editor file exporting `component` and `allTokens`, and a `bootLiveTokens` entry. |
124
82
 
125
83
  ## Report
126
84
 
127
- Say what changed by rule, one line per rule with the count and any visible
128
- shift. Say what was left and why, with the config entry if the user chose to
129
- lower a severity. End with the two commands and their exit codes.
85
+ Say what changed by rule, one line per rule with the count and any visible shift. Say what was left and why, with the config entry if the user chose to lower a severity. End with the two commands and their exit codes.
130
86
 
131
87
  ## Verify
132
88
 
133
- Open `/live-tokens/editor` in dev and change a surface colour and a spacing
134
- step. Every file the loop touched should repaint. One that does not still
135
- holds a literal the checker cannot see, which is worth reporting as a gap in
136
- the checker rather than patching around.
89
+ Open `/live-tokens/editor` in dev and change a surface colour and a spacing step. Every file the loop touched should repaint. One that does not still holds a literal the checker cannot see, which is worth reporting as a gap in the checker rather than patching around.
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: live-tokens-generate-theme
3
- description: Generate a complete live-tokens theme — color, type, and geometry — from a natural-language brief, delegating the type and geometry halves to its sibling skills. Use whenever the user asks for a theme, look, vibe, brand feel, color scheme, or palette by mood, style, era, season, holiday, or hue; when they name only a color (something red-based, green and gold for St. Patrick's Day); or when they refine an existing theme (warmer, more contrast, calmer). Examples: bright and cheerful, dark and moody, brutalist, mid-century modern, Swiss and minimal, cyberpunk neon, editorial magazine, make it feel like a terminal. Not for a single token (use the editor), type alone (live-tokens-pair-fonts), or geometry alone (live-tokens-adjust-geometry).
3
+ description: Generate a complete live-tokens theme (color, type, and geometry) from a natural-language brief, delegating the type and geometry halves to its sibling skills. Use whenever the user asks for a theme, look, vibe, brand feel, color scheme, or palette by mood, style, era, season, holiday, or hue; when they name only a color (something red-based, green and gold for St. Patrick's Day); or when they refine an existing theme (warmer, more contrast, calmer). Examples: bright and cheerful, dark and moody, brutalist, mid-century modern, Swiss and minimal, cyberpunk neon, editorial magazine, make it feel like a terminal. Not for a single token (use the editor), type alone (live-tokens-pair-fonts), or geometry alone (live-tokens-adjust-geometry).
4
4
  ---
5
5
 
6
6
  # Generating a theme from a brief
@@ -145,7 +145,7 @@ This table is the fallback. When the brief matched an entry in the mood or style
145
145
 
146
146
  One adjective moves one dial. Warmer and cooler rotate hue; calmer and louder move chroma; lighter, darker, and moodier move Canvas L and the scheme; more contrast widens the L gap between Canvas and Brand and takes chroma out of the ground rather than adding it to the garnish. Leave every seed the user did not name alone, because a refinement that re-rolls the whole palette reads as a different theme and loses the thing they liked.
147
147
 
148
- ## What each step writes
148
+ ## Files each step writes
149
149
 
150
150
  Color writes `themes/<slug>.json` and opens it. Type and geometry write the unsaved buffers, which the page already runs. One Save in the editor keeps all three; Adopt ships them. Component aliases and gradients carry forward from the live look into a generated theme; user-tuned gradients survive, stock ones rebuild from the new families.
151
151
 
@@ -39,7 +39,7 @@ All four pick one option from a set. The right one depends on **option count**,
39
39
  | `SegmentedControl`| Inline switch between alternative *views of the same data* | Compact pill | 2–4 |
40
40
  | `TabBar` | Switching between *tab panels* (content area swaps below) | Page-section | 2–7 |
41
41
  | `RadioButton` | Form-style selection where the user reviews all options as text | Form-row | Any |
42
- | `MenuSelect` | Hide the option set behind a dropdown to save vertical/horizontal space | Compact dropdown | Any |
42
+ | `MenuSelect` | A list of options, one checked; renders open, so a dropdown toggles it from a `Button` | Open list | Any |
43
43
 
44
44
  - `TabBar` implies "this changes the page"; `SegmentedControl` implies "this is one knob among others."
45
45
  - Use `RadioButton` when labels deserve room to breathe and the user is committing to a larger form.
@@ -63,7 +63,7 @@ All four pick one option from a set. The right one depends on **option count**,
63
63
  | `Dialog` | Modal, blocks page | Confirmations, focused tasks the page can't continue around |
64
64
  | `Panel` | Inline, fixed stage | A demo or preview surface whose height must not reflow |
65
65
 
66
- - Default to `Card`. It's the workhorse. For full-bleed media — cover art, a poster, a chart that reaches its own border — pass `flush` (with `prose={false}`) rather than zeroing its padding tokens from the page.
66
+ - Default to `Card`. It's the workhorse. For full-bleed media (cover art, a poster, a chart that reaches its own border) pass `flush` (with `prose={false}`) rather than zeroing its padding tokens from the page.
67
67
  - Reach for `CollapsibleSection` only when the content is *legitimately secondary* (advanced users open it; most skip). Don't use collapse as a styling choice when the content matters.
68
68
  - `Panel` is a stage, not a content container. It pins its own height so what it shows can resize without moving the page, which is what a component preview or a live example needs and what article content does not. Content goes in `Card`.
69
69
  - **Don't use `Dialog` for routine forms.** Reach for it only when the page cannot meaningfully continue until the user decides (destructive confirmations, payment, sign-in). Routine forms go inline in a `Card`.
@@ -83,7 +83,7 @@ All four pick one option from a set. The right one depends on **option count**,
83
83
  - `Tooltip` is for *what an element means*. **Don't use `Tooltip` as the primary location of important content;** it auto-dismisses and isn't accessible for must-read content.
84
84
  - `Badge` and `CornerBadge` differ only in positioning. `CornerBadge` lives at a `top-right` / `bottom-left` anchor on a parent (notification counts, "NEW" stickers).
85
85
 
86
- ## Display family: what the page shows rather than what it asks
86
+ ## Display family: shown, not asked
87
87
 
88
88
  - `Image` frames a picture in the flow at one of four sizes, with an optional hover zoom. It is the default for any picture the page simply shows.
89
89
  - `ImageLightbox` adds click-to-open at full size and takes an array for a gallery. Use it when the detail is the point (screenshots, artwork, charts that need reading), and not for decoration: it puts a modal behind every picture it wraps.
@@ -108,4 +108,4 @@ All three can express a binary choice. The right one depends on what the choice
108
108
 
109
109
  ---
110
110
 
111
- If nothing in the catalogue fits (a `Slider`, a `DatePicker`, a `Stepper`, a custom widget), author it via **live-tokens-create-component**. **Don't reach for a custom component before checking the catalogue;** a custom component is a maintenance commitment.
111
+ If nothing in the catalogue fits (a `DatePicker`, a `Stepper`, a custom widget), author it via **live-tokens-create-component**. **Don't reach for a custom component before checking the catalogue;** a custom component is a maintenance commitment.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,87 @@
1
1
  # Changelog
2
2
 
3
+ ## 0.73.0 — The skill atlas ships from the package
4
+
5
+ ### Added
6
+
7
+ - **A public export for the skill atlas, `@motion-proto/live-tokens/skill-atlas`.**
8
+ The atlas is a Svelte component that diagrams the reasoning tree behind each
9
+ bundled skill, with the source `SKILL.md` and its reference files alongside
10
+ so a reader can see which lines drive which step. It carries no route of its
11
+ own; a consumer mounts it wherever it likes. `live-tokens-online` is its
12
+ first consumer, mounting it at its existing `/skills` route. Skill text
13
+ reaches the component through a generated module built from `.claude/skills`
14
+ and gated by `check:skill-sources`; the trees each carry a digest of the
15
+ `SKILL.md` they cite and are gated by `check:skill-atlas`. Both run in
16
+ `prepublishOnly`.
17
+
18
+ ### Changed
19
+
20
+ - **`live-tokens-build-page` lays out the page before it places columns.**
21
+ The Layout section opens with bands: name each by its job, put a tool
22
+ page's stage on top and its toolbar along the bottom edge, separate bands
23
+ with space and a rule, and stretch a band's boxes to one height. Two new
24
+ subsections follow. *Containers by job* says what `Panel`, `Card`, a bare
25
+ compact `Card` with its own text-style label, and a toolbar are each for,
26
+ and that a card header is typed by the card's own tokens at 2xl. *Density*
27
+ covers `size="small"` in toolbars and compose rows, forwarding `size` from
28
+ a project component, text inside a card body inheriting the card's size,
29
+ and toggling `MenuSelect` from a `Button`. Verify now asks for a look at
30
+ the page band by band, since the checker cannot see a layout. The gap
31
+ came from a studio page whose card headers, buttons, and inherited body
32
+ text all ran large with every check green; `docs/build-page-gap-analysis.md`
33
+ records it.
34
+
35
+ - **`live-tokens-build-page` opens Layout with the laws behind its rules.**
36
+ A short block before the bands states what a layout is for: the page
37
+ shows one thing, each mark that is not content must do a job no other mark does,
38
+ separate with the smallest difference that separates (space, then a
39
+ hairline rule, then a second surface), rank content, labels, and
40
+ scaffolding on their own tokens, show related items side by side, and
41
+ give a tool page's space to the stage. Verify adds a look from a distance,
42
+ a removal question for each border and header bar, and a check of the
43
+ reading order. The laws are Tufte's (smallest effective difference,
44
+ 1+1=3, layering and separation, administrative debris), with
45
+ Müller-Brockmann and Refactoring UI as the working restatements;
46
+ `references/layout-sources.md` in the skill names each source and where
47
+ it lands.
48
+
49
+ - **`live-tokens-pick-component` says `MenuSelect` renders open.** The
50
+ selection table called it a compact dropdown; the shipped component is a
51
+ list, and a dropdown is a `Button` that toggles it.
52
+
53
+ ## 0.72.1 — The compliance skills have a spine
54
+
55
+ ### Changed
56
+
57
+ - **`live-tokens-check-compliance` and `live-tokens-fix-findings` open with a
58
+ numbered workflow**, the same spine the other six skills have: run the
59
+ command, read the result, apply the recipe, re-run, hand off. Both were
60
+ prose-first, so a reader (and the Skill Atlas that draws them) had no steps,
61
+ no gate, and no hand-off to find. fix-findings now also covers the four
62
+ wiring rules its table skipped (`invalid-id`, `no-tokens`,
63
+ `missing-component-const`, `missing-all-tokens`).
64
+
65
+ - **`live-tokens-create-component` is 189 lines, down from 247.** The
66
+ standalone Toggle walkthrough is folded into the worked-examples list, the
67
+ verification checklist no longer restates the checker step, and the
68
+ registration caveat is shorter. Nothing a consumer needs to author a
69
+ component was removed.
70
+
71
+ - **The sketch reference's inner-part example carries its reserved class.**
72
+ The prose said a drawn part takes its own class and its own five
73
+ `--sketch-*` values; the code under it showed only the CSS, so a part
74
+ authored from the example was left crisp inside a drawn box.
75
+
76
+ ### Fixed
77
+
78
+ - **`live-tokens-build-page` no longer promises a Cmd+G shortcut.** There is
79
+ none; the columns overlay is the vertical-lines button in the overlay's
80
+ header.
81
+
82
+ - **`live-tokens-pick-component` no longer lists `Slider` as a component the
83
+ catalogue lacks.** It shipped in 0.71.0.
84
+
3
85
  ## 0.72.0 — The contract a consumer can run
4
86
 
5
87
  ### Added
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@motion-proto/live-tokens",
3
- "version": "0.72.0",
3
+ "version": "0.73.0",
4
4
  "type": "module",
5
5
  "description": "Design token editor with live CSS variable editing. Svelte 5 + Vite 8.",
6
6
  "keywords": [
@@ -101,6 +101,11 @@
101
101
  "svelte": "./src/editor/docs/Docs.svelte",
102
102
  "default": "./src/editor/docs/Docs.svelte"
103
103
  },
104
+ "./skill-atlas": {
105
+ "types": "./src/editor/skill-atlas/SkillAtlas.svelte.d.ts",
106
+ "svelte": "./src/editor/skill-atlas/SkillAtlas.svelte",
107
+ "default": "./src/editor/skill-atlas/SkillAtlas.svelte"
108
+ },
104
109
  "./backdrop": {
105
110
  "svelte": "./src/system/backdrop/index.ts",
106
111
  "types": "./src/system/backdrop/index.ts",
@@ -154,15 +159,17 @@
154
159
  "check:token-contract": "node scripts/check-token-contract.mjs",
155
160
  "check:preset-themes": "node scripts/check-preset-themes.mjs",
156
161
  "check:skills": "node scripts/check-skills.mjs",
162
+ "check:skill-sources": "node scripts/sync-skill-sources.mjs --check",
157
163
  "check:skill-atlas": "node scripts/sync-skill-atlas.mjs",
158
164
  "sync:component-defaults": "node scripts/sync-component-defaults.mjs --write",
159
165
  "sync:docs": "node scripts/sync-docs.mjs --write",
166
+ "sync:skill-sources": "node scripts/sync-skill-sources.mjs --write",
160
167
  "sync:skill-atlas": "node scripts/sync-skill-atlas.mjs --write",
161
168
  "seed:preset-theme": "node scripts/seed-preset-theme.mjs",
162
169
  "collapse:theme": "node scripts/collapse-theme-to-default.mjs",
163
170
  "check:smoke-install": "bash scripts/smoke-install.sh",
164
171
  "check:smoke-create": "bash scripts/smoke-create.sh",
165
- "prepublishOnly": "npm run check:no-style-imports && npm run check:no-tooling-imports && npm run check:slot-prose && npm run check:overlay-portal && npm run check:editor-font-isolation && npm run check:component-defaults && npm run check:pages && npm run check:production-is-default && npm run check:docs-content && npm run build:lib && npm run check:token-contract && npm run check:preset-themes && npm run check:skills && npm run check:skill-atlas && npm run check:smoke-install && npm run check:smoke-create"
172
+ "prepublishOnly": "npm run check:no-style-imports && npm run check:no-tooling-imports && npm run check:slot-prose && npm run check:overlay-portal && npm run check:editor-font-isolation && npm run check:component-defaults && npm run check:pages && npm run check:production-is-default && npm run check:docs-content && npm run build:lib && npm run check:token-contract && npm run check:preset-themes && npm run check:skills && npm run check:skill-sources && npm run check:skill-atlas && npm run check:smoke-install && npm run check:smoke-create"
166
173
  },
167
174
  "peerDependencies": {
168
175
  "@sveltejs/vite-plugin-svelte": "^7.0",
@@ -16,6 +16,19 @@ npx @motion-proto/live-tokens setup-claude
16
16
  This copies the bundled skills into your project's `.claude/skills/`. Once
17
17
  they're there, Claude Code picks them up automatically.
18
18
 
19
+ ## Browse the skill atlas
20
+
21
+ The package also ships a Skill Atlas component: a diagram of the reasoning
22
+ behind each bundled skill, with its `SKILL.md` and reference files alongside
23
+ so you can see exactly which lines drive which step. Import it from
24
+ `@motion-proto/live-tokens/skill-atlas` and mount it on a route of your own:
25
+
26
+ ```js
27
+ '/skills': {
28
+ lazy: () => import('@motion-proto/live-tokens/skill-atlas'),
29
+ },
30
+ ```
31
+
19
32
  ## Ask for a component
20
33
 
21
34
  Describe what you want in plain English. Phrases like these trigger the skill:
@@ -3,7 +3,7 @@
3
3
 
4
4
  export const docContent: Record<string, string> = {
5
5
  "01-overview": "# Overview\n\nLiveTokens is a design system for building Svelte microsites quickly. You\nstyle your site by editing tokens and components in a live editor. When it looks right, you save the theme and ship it.\n\n## How it works\n\n- The editor runs in your dev server, on top of your real pages. You style in\n context, not in a separate sandbox.\n- Every change updates a CSS variable, so the page repaints instantly. No\n reload, no build step.\n- Saving writes a small JSON file into your project. Shipping bakes your chosen\n theme into a plain CSS file that the build bundles.\n- The editor is dev-only. Production ships plain CSS variables and the\n components you used, nothing else.\n\n## What you can edit\n\n- **Tokens**: the design-system primitives, colour palettes, type, spacing,\n radius, shadow, and gradients, that apply across your whole site.\n- **Components**: the package ships about 25 editable components (Button,\n IconButton, Card, Dialog, Table, and more). You style components by changing\n the tokens assigned to each property.\n\n## Where to go next\n\n- **[Getting started](getting-started.md)**: scaffold a project and make your\n first edit.\n- **[Editing tokens](editing-tokens.md)**: a tour of the editor.\n- **[Sketch mode](sketch-mode.md)**: redraw the page by hand.\n- **[Themes](themes-workflow.md)**: save, switch, and ship.\n- **[Creating components](creating-components.md)**: make your own components\n editable.\n",
6
- "creating-components": "# Creating components\n\nThe package ships about 25 editable components. When you need one it doesn't\nhave, you can make your own Svelte component editable, so anyone using the\neditor can re-point its colours, type, and spacing without touching code.\n\nThe simplest way is to ask Claude. The package bundles a Claude Code skill that\nknows the conventions, writes the files, and checks the result for you.\n\n## Install the skills\n\n```bash\nnpx @motion-proto/live-tokens setup-claude\n```\n\nThis copies the bundled skills into your project's `.claude/skills/`. Once\nthey're there, Claude Code picks them up automatically.\n\n## Ask for a component\n\nDescribe what you want in plain English. Phrases like these trigger the skill:\n\n- \"Add a Toggle component to live-tokens\"\n- \"Make this Svelte component editable in the live-tokens editor\"\n- \"Create a Stat component with a value and a label\"\n\nClaude asks any clarifying questions it needs (which variants, which states,\nwhich parts), then writes the component, registers it with the editor, and runs\nits verification checklist. When it finishes, open `/live-tokens/components` to see your new\ncomponent in the editor and confirm everything works.\n\n## What you get\n\n- A runtime component whose editable properties default to your theme tokens.\n- An editor entry that appears under **Custom** in the `/live-tokens/components` view.\n- The naming and wiring handled for you, so the component fits the system.\n\nAdvanced authors who want to write a component by hand can read the naming and\nstate-model conventions shipped in the package\n(`src/system/styles/CONVENTIONS.md` and the skill's own `SKILL.md`).\n",
6
+ "creating-components": "# Creating components\n\nThe package ships about 25 editable components. When you need one it doesn't\nhave, you can make your own Svelte component editable, so anyone using the\neditor can re-point its colours, type, and spacing without touching code.\n\nThe simplest way is to ask Claude. The package bundles a Claude Code skill that\nknows the conventions, writes the files, and checks the result for you.\n\n## Install the skills\n\n```bash\nnpx @motion-proto/live-tokens setup-claude\n```\n\nThis copies the bundled skills into your project's `.claude/skills/`. Once\nthey're there, Claude Code picks them up automatically.\n\n## Browse the skill atlas\n\nThe package also ships a Skill Atlas component: a diagram of the reasoning\nbehind each bundled skill, with its `SKILL.md` and reference files alongside\nso you can see exactly which lines drive which step. Import it from\n`@motion-proto/live-tokens/skill-atlas` and mount it on a route of your own:\n\n```js\n'/skills': {\n lazy: () => import('@motion-proto/live-tokens/skill-atlas'),\n},\n```\n\n## Ask for a component\n\nDescribe what you want in plain English. Phrases like these trigger the skill:\n\n- \"Add a Toggle component to live-tokens\"\n- \"Make this Svelte component editable in the live-tokens editor\"\n- \"Create a Stat component with a value and a label\"\n\nClaude asks any clarifying questions it needs (which variants, which states,\nwhich parts), then writes the component, registers it with the editor, and runs\nits verification checklist. When it finishes, open `/live-tokens/components` to see your new\ncomponent in the editor and confirm everything works.\n\n## What you get\n\n- A runtime component whose editable properties default to your theme tokens.\n- An editor entry that appears under **Custom** in the `/live-tokens/components` view.\n- The naming and wiring handled for you, so the component fits the system.\n\nAdvanced authors who want to write a component by hand can read the naming and\nstate-model conventions shipped in the package\n(`src/system/styles/CONVENTIONS.md` and the skill's own `SKILL.md`).\n",
7
7
  "editing-tokens": "# Editing tokens\n\nA tour of the editor. The page behind it repaints on every change; saving\nwrites a theme file you can reload later.\n\nThe editor has four views:\n\n- **Tokens**: the design-system primitives (colour, type, spacing, and so on).\n They apply everywhere your site uses them.\n- **Color Wheel**: the harmony wheel, the palette curves, and the story your colours\n tell across a page.\n- **Components**: per-component editors. Re-Assign what tokens a component uses\n without changing the underlying system.\n- **Sketchstyle**: an effect layer that redraws the page by hand. See\n [Sketch mode](sketch-mode.md).\n\nThis page covers **Tokens**. For components, see\n[Creating components](creating-components.md).\n\n## Palettes\n\nMost colour work happens here. Each palette (Brand, Accent, Neutral, Canvas,\nSuccess, Warning, Info, Danger, and a few more) has:\n\n- **Base colour.** Pick a hex; the palette derives an 11-step ramp (100 to 950)\n from it.\n- **Curves.** Three curves shape the ramp, in stack order: Hue, Saturation,\n Lightness. Drag the handles to bias it warmer or cooler, more or less\n saturated, darker or lighter. Hue drifts the ramp's temperature without\n moving contrast, because OKLCH hue rotation is close to lightness-preserving.\n It holds ±45 degrees; a bigger shift belongs on the base colour or the\n harmony axis.\n- **Overrides.** Lock a single step to a hand-picked hex when the curve doesn't\n land where you want.\n\nEditing a palette base ripples through every colour that depends on it, in real\ntime. Colours use OKLCH, so the ramp stays perceptually even across hues\nwithout muddy mid-tones.\n\n## Type\n\n- **Fonts.** Add sources from Google Fonts, Adobe (Typekit), a CSS URL, or an\n inline `@font-face`. The font loads in the page as soon as you add it.\n- **Stacks.** Named font cascades you reference by token, such as a display\n stack and a body stack.\n- **Sizes and weights.** A t-shirt scale (xs, sm, md, lg, xl, 2xl…) for size and\n a numeric scale (100 to 900) for weight.\n\n## Spacing, radius, shadow\n\nNumeric scales with a slider per step.\n\n- **Spacing**: the padding, gap, and margin scale.\n- **Radius**: none through full.\n- **Shadow**: colour, offset, blur, spread, and opacity per step, with stacked\n shadows supported.\n\nChange a step and every element using it repaints.\n\n## Washes and gradients\n\n- **Scrims** are translucent layers that dim what sits behind them, like the\n one a dialog draws over the page. Set a colour and opacity per stop.\n- **Tints** are the opposite operation: they shade the surface they sit on\n rather than dimming what is behind it, which is what a hover needs.\n- **Gradients** are reusable gradient tokens with a stop list and direction, for\n hero panels and accent backgrounds.\n\n## Columns\n\nThe page-grid overlay. Set column count, gutter, and outer margin, and toggle\nthe visual guide with `Cmd/Ctrl+G`. Pages built on the column system reflow\nlive.\n\n## Saving\n\nThe editor saves to your browser continuously, so work survives a reload\nmid-edit. Writing a file is a separate step: the **Theme** panel at the foot of\nthe sidebar has **Save**, **Save As**, and **Load**, and each theme is one JSON\nfile under `src/live-tokens/data/themes/`.\n\nThe header gives you undo/redo (`Cmd/Ctrl+Z`, `Cmd/Ctrl+Shift+Z`). You can keep\nmany themes side by side; one is open at a time, and only **Adopt** publishes\none. See [Themes](themes-workflow.md) for the full lifecycle.\n",
8
8
  "getting-started": "# Getting started\n\nScaffold a live token site in a moments. You need Node 20 or later, a\npackage manager (npm, pnpm, or yarn), and a browser. Open claude code in your repo and start building.\n\n## Scaffold a new app\n\n```bash\nnpm create @motion-proto/live-tokens@latest my-app\ncd my-app\nnpm install\nnpm run dev\n```\n\nOpen the URL Vite prints (usually `http://localhost:5173`). You get a\none-page Svelte + Vite app that depends on the published package, with the\neditor wired up and the full component set ready to import.\n\n`npx @motion-proto/live-tokens create my-app` runs the same scaffold without\nthe initialiser package.\n\n### What the scaffold gives you\n\nEvery editable file lives under `src/` and is committed, so `npm install` and\nversion upgrades never touch your styles. The package code stays in\n`node_modules`.\n\n| Path | What it is |\n|------|------------|\n| `src/pages/Home.svelte` | The starter page. Replace it with your own content. |\n| `src/App.svelte` | Your routes. `<LiveTokensRouter>` adds dev-only routes under a reserved `/live-tokens/*` namespace: `/live-tokens/editor`, `/live-tokens/components`, and `/live-tokens/docs`. |\n| `src/system/styles/tokens.css` | Your base token vocabulary, hand-authored. |\n| `src/styles/site.css` | Themed page typography, yours to edit. |\n\n## Your first edit\n\n1. Run `npm run dev` and open the home page.\n2. Click **Open Token Editor**, or visit `/live-tokens/editor`. The editor opens beside\n the page.\n3. Open **Palettes**, pick **Brand**, and change the base hex. The page\n repaints as you type.\n4. In the **Theme** panel at the foot of the sidebar, choose **Save As**. Your\n theme appears as JSON under `src/live-tokens/data/themes/`.\n5. Reload. The editor reopens on your theme, so the page returns as you left\n it.\n\n## What you just changed\n\nEvery edit sets a CSS custom property on `:root`. Your components read those\nproperties through `var(--...)`. There is no token build step and no\npreprocessor rewriting your code: the page renders against plain CSS variables\nthe editor swaps live.\n\nTo ship, click **Adopt** in the Theme panel. That saves the open theme and bakes\nit into `src/live-tokens/data/tokens.generated.css`, which your build bundles\nalongside `tokens.css`. Adopt is the only action that changes what your site\nships, so try any theme you like first. The editor itself never reaches\nproduction.\n\nAlready have a Svelte 5 + Vite app? The\n[README](https://github.com/motionproto/live-tokens#readme) covers installing\ninto an existing project.\n\n## Where to go next\n\n- **[Editing tokens](editing-tokens.md)**: a tour of the editor.\n- **[Themes](themes-workflow.md)**: save, switch, and ship.\n- **[Creating components](creating-components.md)**: make your own component\n editable.\n",
9
9
  "light-and-dark": "# Light and dark\n\nSome things on a page cannot be written as a token. A wordmark drawn in white\ndisappears on a pale theme. Ink that multiplies onto paper vanishes on a dark\none. A photograph behind a headline is dark no matter what the palette says.\n\nEach of those needs the same fact first: which way does the surface behind this\nthing lean? One attribute carries it.\n\n## The attribute\n\n`data-backdrop` is either `light` or `dark`, and it does two things at once: it\nselects, so a rule can key on it, and it sets `color-scheme`, so every\n`light-dark()` under it resolves the half that reads.\n\n```css\n.title {\n color: light-dark(var(--color-black), var(--color-white));\n}\n```\n\nThat line is right on both sides of the theme, and it is right inside a dark\nband on a pale page, because the nearest `color-scheme` wins.\n\n## Stating it\n\nPut it in the markup when the surface knows its own tone — a hero over a\nphotograph, a plate that stays pale in every theme:\n\n```svelte\n<div class=\"hero-panel\" data-backdrop=\"dark\">\n```\n\nA stated tone beats any measurement, and it inherits, so everything inside the\npanel resolves against it.\n\n## Measuring it\n\nWhere the tone is a property of the theme rather than of the markup, let it be\nmeasured:\n\n```svelte\n<script>\n import { backdrop } from '@motion-proto/live-tokens/backdrop';\n</script>\n\n<section use:backdrop>\n```\n\nThe action reads whatever actually paints behind the element — the nearest\nancestor with an opaque fill, averaged across its gradient stops, falling back\nto the theme's `--page-bg` — and stamps the answer. It re-reads when the theme\nchanges, which the editor does by rewriting custom properties with no reload,\nso the stamp follows a live edit.\n\nThe page itself is stamped for you: the build bakes the production theme's\npolarity into `tokens.generated.css`, so the first paint is already right, and\n`syncDocumentBackdrop()` keeps `<html>` current as themes switch.\n\n```ts\nimport { syncDocumentBackdrop } from '@motion-proto/live-tokens/backdrop';\n\nsyncDocumentBackdrop();\n```\n\n## Reading it from JavaScript\n\nAnything that paints outside CSS — a canvas, a WebGL uniform, an `<img>` that\ncomes in two versions — asks the same question through the same module:\n\n```ts\nimport { isLightBackdrop, watchBackdrop, cssColorToHex } from '@motion-proto/live-tokens/backdrop';\n\nconst stop = watchBackdrop(logoEl, {\n stamp: false,\n onChange: (polarity) => (src = polarity === 'light' ? darkMark : lightMark),\n});\n```\n\n`isLightBackdrop(el)` answers once. `watchBackdrop` keeps answering and returns\na stop function. `cssColorToHex` resolves any CSS colour — including the\n`oklch()` a token holds — to a hex a non-CSS consumer can take.\n\n## What it does not do\n\nPolarity is a property of a surface, not of a component, so nothing is stamped\nfor you below `<html>`: a section that needs an answer either states one or asks\nfor one. And a measurement reads the paint at the moment it runs — an element\nthat scrolls from a pale band onto a dark one keeps the answer it was given.\nState the tone on each band instead.\n",