@radicool/throughline 0.13.0 → 0.15.0

package/adapters/cursor/.cursor/rules/component-pipeline.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Take a single new component from Figma to fully-built-and-storied code, end to end — build it in Figma, sync any new tokens it introduced, then build its code component and stories. This is an orchestrator that sequences the component-builder, token-sync-layer, and storybook-chromatic-builder skills with a human confirmation between each stage. Use this when the user wants to add a new component to an existing design system, ship a component end-to-end, or run the full new-component flow. Also trigger on \"/new-component\" or when someone says they want one component built all the way through to code. Make sure to use this when the design system foundations already exist and the user wants to add one more component through the whole pipeline."
+description: "Take a single new component from Figma to fully-built-and-storied code, end to end — build it in Figma, sync any new tokens it introduced, then build its code component and stories. Orchestrates component-builder, token-sync-layer, and storybook-chromatic-builder with a human confirmation between each stage. Use this when the user wants to add a new component to an existing design system, ship a component end-to-end, or run the full new-component flow. Also trigger on \"/new-component\" or when someone wants one component built all the way through to code."
 alwaysApply: false
 ---
 # Component pipeline (orchestrator)

package/adapters/cursor/.cursor/rules/design-system-audit.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Measure a pre-existing design system before retrofitting it onto tokens — size the code-side color surface and inventory the existing Figma file with verified per-class reads, then compute how semantic the system already is so the retrofit is right-sized. This is a PROCESS skill and the brownfield front door. Use this when retrofitting a design system onto a mature codebase and an already-populated Figma file, when the user wants to audit an existing system, size a retrofit, count existing tokens/variables/bindings, or figure out how much work a migration is. Also trigger when figma-environment-setup detects a brownfield situation (existing repo or populated Figma file), before any building. Make sure to use this whenever someone is converging two mature, drifted artifacts rather than building greenfield."
+description: "Measure a pre-existing design system before retrofitting it onto tokens, so the retrofit is right-sized. This is a PROCESS skill and the brownfield front door. Use this when retrofitting a design system onto a mature codebase and an already-populated Figma file, when the user wants to audit an existing system, size a retrofit, count existing tokens/variables/bindings, or figure out how much work a migration is. Also trigger when figma-environment-setup detects a brownfield situation (existing repo or populated Figma file), before any building."
 alwaysApply: false
 ---
 # Design-system audit (brownfield front door)
@@ -60,6 +60,23 @@ counts:
 repo with no Tailwind simply scores `0` there. Detect what the repo actually uses (is
 there a `tailwind.config`? SCSS? CSS-in-JS?) and explain the counts in those terms.
 
+## Step 1.5 — Size the documentation surface
+
+Inventory existing documentation the same way the code surface is sized — from
+**verified reads, never assumptions**. Per component (or per code component when no
+Figma component exists yet), record whether usage docs already exist and where:
+
+- **Code:** JSDoc/TSDoc on the component, an `.mdx` doc page, a per-component
+  README.
+- **Figma:** a populated component `description` field.
+
+Write the totals to `audit.docSurface` in the manifest, e.g. `{ "documented": 12,
+"undocumented": 34, "sources": { "codeJsdoc": 8, "mdx": 4, "figmaDescription": 6,
+"readme": 3 } }`. This right-sizes the documentation retrofit (how much exists to
+adopt vs. author from scratch) so `retrofit-planner`'s `docs` phase can be planned
+against real numbers. See `.throughline/references/component-doc-schema.md`
+for what a full record contains.
+
 ## Step 2 — Inventory the Figma file (verified per-class reads)
 
 Variables, text styles, and effect/paint styles are **different surfaces** — read each
@@ -107,6 +124,9 @@ Set `tokens.intakeMode: "retrofit"` (this skill establishes the brownfield path
 owns this transition). Append `design-system-audit` to `completedSkills`.
 
 Then recommend the next step:
+- Report the documentation debt from `audit.docSurface` (documented vs.
+  undocumented) and note that the retrofit's `docs` phase will adopt existing docs
+  before authoring the gaps.
 - If the user wants the guided, gated end-to-end retrofit → **`retrofit-planner`**
   (the orchestrator; recommended for multi-session retrofits).
 - If they only want the crosswalk backbone next → **`token-crosswalk-builder`** (it

package/adapters/cursor/.cursor/rules/figma-environment-setup.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Set up the local working folder and connect Cursor to Figma so the design-system skills can read and write variables, styles, and components. This is a SETUP/PROCESS skill — it must run BEFORE brainstorming, not after it, because there is nothing to brainstorm until the environment exists. Invoke this skill immediately when the user wants to start, set up, or begin building a design system — phrases like 'let's setup my design system', 'let's get started', 'connect Figma', or 'build my design system' should all trigger this skill first, ahead of brainstorming. Also trigger when the user wants to fix a broken Figma connection, or mentions the Figma Console MCP, the desktop bridge plugin, or a Figma access token. It is the required foundation everything else depends on — always run it before any other design-system skill."
+description: "Set up the local working folder and connect Cursor to Figma so the design-system skills can read and write variables, styles, and components. Run this BEFORE brainstorming and before any other design-system skill. Invoke it immediately when the user wants to start, set up, or begin building a design system — phrases like 'let's setup my design system', 'let's get started', 'connect Figma', or 'build my design system' should all trigger this skill first, ahead of brainstorming. Also trigger when the user wants to fix a broken Figma connection, or mentions the Figma Console MCP, the desktop bridge plugin, or a Figma access token."
 alwaysApply: false
 ---
 # Figma environment setup

package/adapters/cursor/.cursor/rules/icon-system-builder.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Build an icon system in Figma — a dedicated \"Icons\" page populated with the user's chosen icon library (Lucide, Material, or custom SVGs) as well-named, scalable components — using the fastest, most-automated mechanism per library (for Lucide, batch-fetching the curated subset's official SVGs from the source repo and componentizing them hands-off; for Material, the official community file or importer plugin) rather than hand-generating icons or making the user copy components by hand. Use this when the user wants to set up icons, add an icon library, import Lucide or Material icons, create icon components, or build an icon set in Figma. Also trigger when the user mentions iconography, an icon page, or needs icons for their components. Make sure to use this whenever someone needs a managed set of icon components in their Figma design system."
+description: "Build an icon system in Figma — a dedicated \"Icons\" page of well-named, scalable icon components from Lucide, Tabler, Phosphor, Material, or custom SVGs. Use this when the user wants to set up icons, add an icon library, import Lucide or Material icons, create icon components, or build an icon set in Figma. Also trigger when the user mentions iconography, an icon page, or needs icons for their components."
 alwaysApply: false
 ---
 # Icon system builder

package/adapters/cursor/.cursor/rules/repository-builder.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Graduate the local design-system folder into a real monorepo — a pnpm + Turborepo workspace with packages for tokens and UI components and room for apps — and walk the user from a plain folder to local git to a GitHub remote with PRs and CI. Use this when the user wants to set up a repo, create a GitHub repository, add version control, turn their folder into a real project, or prepare to sync tokens to code. Also trigger when the user mentions monorepo, Turborepo, pnpm workspace, GitHub, version control, or when the token-sync or Storybook skills report that a repo isn't set up yet. Make sure to use this skill when someone is moving from the Figma/design phase into the code phase, even if they just say \"I want to turn this into code\" — it's the bridge between the two halves."
+description: "Graduate the local design-system folder into a real monorepo — a pnpm + Turborepo workspace with packages for tokens and UI components — and walk the user from a plain folder to local git to a GitHub remote with PRs and CI. Use this when the user wants to set up a repo, create a GitHub repository, add version control, turn their folder into a real project, or say \"I want to turn this into code\". Also trigger when the user mentions monorepo, Turborepo, pnpm workspace, GitHub, version control, or when the token-sync or Storybook skills report that a repo isn't set up yet."
 alwaysApply: false
 ---
 # Repository builder
@@ -110,6 +110,20 @@ in it" — they already have a working local repo.
 On success, set `workspace.stage` and `repo.stage` to `github` and record
 `repo.remote`. Append `repository-builder` to `completedSkills`.
 
+### Adopt the documentation store
+
+The folder-resident documentation store at `design-system/docs/` (canonical
+`*.doc.json` records plus the generated `index.json` + `llms.txt`) already exists
+from the Figma phase. Bring it under version control as-is — **do not relocate it**
+(the path is stable across folder→repo, and every manifest `doc.path` points at it).
+Ensure it is committed (not git-ignored).
+
+Wire the documentation drift gate into the repo's verification so it runs in CI
+alongside `tokens:validate`: add a `docs:check` step (the `docs-check.mjs` script is
+installed by `storybook-chromatic-builder`; if code hasn't been set up yet, note
+that the gate comes online with the Storybook step). `docs:check` exits non-zero on
+drift; Figma surfaces report `edit-unverified` and are checked in a Figma session.
+
 ## Secrets: the part most people have never done
 
 This is where users with low coding experience get stuck — many have never made

package/adapters/cursor/.cursor/rules/retrofit-planner.mdc

@@ -1,10 +1,11 @@
 ---
-description: "Orchestrate a full brownfield design-system retrofit end to end — audit, refine variables in place, rebind components, sync, capture a Chromatic baseline, retrofit the code with dual output, then remove the old tokens only after a zero-reference grep — with a human confirmation gate between every phase. Use this when the user wants to run a complete retrofit, migrate a mature codebase and populated Figma file onto tokens, resume an in-progress retrofit, or be walked through the safe retrofit sequence. Also trigger after design-system-audit has sized the system, or when figma-environment-setup detects an in-progress retrofit. Make sure to use this whenever someone wants the guided, gated, multi-session brownfield retrofit rather than running the individual skills by hand."
+description: "Orchestrate a full brownfield design-system retrofit end to end — audit, refine, rebind, sync, baseline, code, docs, cleanup — with a human confirmation gate between every phase. Use this when the user wants to run a complete retrofit, migrate a mature codebase and populated Figma file onto tokens, resume an in-progress retrofit, or be walked through the safe retrofit sequence. Also trigger after design-system-audit has sized the system, or when figma-environment-setup detects an in-progress retrofit."
 alwaysApply: false
 ---
 # Retrofit planner (orchestrator)
 
-Sequences a brownfield retrofit through the safe 7-phase order, gating each phase on a
+Sequences a brownfield retrofit through the safe seven-phase order (with `docs` inserted
+as a gated Phase 6.5), gating each phase on a
 human confirmation. Like `component-pipeline`, this skill holds **zero domain logic of
 its own** — it is a sequencer that invokes the real skills and the phase work, and only
 updates the manifest fields it owns (`retrofit.*`, `completedSkills`). All the
@@ -106,6 +107,25 @@ triad as you go — `check-types`, `build-storybook` + Chromatic, **and run the
 + spot-check 5–7 routes (the build alone is blind to story-unreachable SCSS). **Gate:**
 confirm the triad passes before continuing.
 
+### Phase 6.5 — `docs` (adopt existing documentation, then fill gaps)
+
+Set `retrofit.phase = "docs"`. Bring the documentation layer onto the system's
+components **adopt-first**, so no existing human-written doc is lost:
+
+1. **Adopt.** For each component, run the doc-authoring ingest (Step 4.5 of
+   `component-builder`): read existing code JSDoc/MDX/README and Figma
+   `description`, seed the canonical `.doc.json` marked `provenance: imported`, and
+   stamp fingerprints. This first pass **claims** existing content — it is not a
+   re-render and must not overwrite it.
+2. **Fill gaps.** Run the remaining generation layers (infer → enrich → specialize
+   → interview) only for blocks the adoption did not populate; the user approves.
+3. **Project + gate.** Render the code surfaces (Step 5.5 of
+   `storybook-chromatic-builder`), run `docs:digest`, and run `docs:check` — it
+   should pass (surfaces just rendered) with Figma surfaces `edit-unverified`.
+
+Confirm with the user before writing, consistent with every other phase. On a large
+system, size the batch from `audit.docSurface` and adopt in reviewable chunks.
+
 ### Phase 7 — `cleanup`
 
 Remove the old token outputs **only after** the repo-wide token-removal guard returns

package/adapters/cursor/.cursor/rules/storybook-chromatic-builder.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Stand up Storybook in the monorepo, build code components matching the Figma design system (consuming the synced tokens and implementing the captured slot contracts), generate stories for every component, set up Chromatic for visual regression testing, and wire Code Connect when the user's Figma plan supports it. Use this when the user wants to set up Storybook, build component stories, add visual regression testing, set up Chromatic, connect Figma components to code, or build the code side of their design system. Also trigger after components and token sync exist, when moving the component library into code. Make sure to use this whenever someone wants their Figma components realized as documented, tested code."
+description: "Stand up Storybook in the monorepo, build code components matching the Figma design system, generate stories for every component, set up Chromatic for visual regression testing, and wire Code Connect when the user's Figma plan supports it. Use this when the user wants to set up Storybook, build component stories, add visual regression testing, set up Chromatic, connect Figma components to code, or build the code side of their design system. Also trigger after components and token sync exist, when moving the component library into code."
 alwaysApply: false
 ---
 # Storybook + Chromatic builder
@@ -31,6 +31,17 @@ system). Wire it to consume `packages/tokens` output so stories render with the
 real design tokens (import the generated CSS/theme). Checkpoint: confirm
 Storybook runs and shows the token-themed canvas.
 
+Install the documentation scripts alongside the token scripts: copy the five
+files and register the three npm scripts listed under **Documentation scripts —
+install as a set** in `.throughline/scripts/README.md`. That table is
+the single source of truth for what a consuming repo gets; do not restate the
+list here.
+
+These are the documentation analog of `tokens:validate`; see
+`.throughline/scripts/README.md`. This copy is setup, not a forever-fork:
+`/document-component` re-checks these files' freshness on every run and refreshes
+them from the plugin when it has moved on.
+
 **pnpm build-script allowlist (first-run gotcha).** On pnpm workspaces, the
 `@storybook/react-vite` install pulls `esbuild`, whose postinstall is blocked by
 pnpm's default `onlyBuiltDependencies` policy — Storybook then fails to start with a
@@ -153,6 +164,43 @@ Configure Chromatic to snapshot everything (do **not** set `onlyChanged`), and
 verify a token-only PR re-snapshots all stories — they should flip orange against
 the green baseline.
 
+### Usage & cost guardrails
+
+The full-snapshot default above is the right call for catching regressions, and it
+is also the **maximum-usage** choice: every story, every run. Chromatic bills per
+snapshot, so name this cost shape to the user when you set Chromatic up, and put the
+guardrails in *before* the first big token PR, not after the bill.
+
+What Chromatic actually offers (re-verify the live numbers at
+`chromatic.com/pricing` — they drift):
+
+- **Free plan (~5,000 snapshots/month):** testing **auto-pauses** when the ceiling
+  is hit. No surprise bill, but visual-regression coverage silently *stops* until
+  the monthly reset or an upgrade. For a full-suite design system that ceiling
+  arrives fast — treat a *paused* build as a red flag, not a passing one.
+- **Paid plans: no hard spending cap.** Overage snapshots auto-bill at month-end.
+  The only native guardrail is **usage alerts** — an email when consumption crosses
+  a threshold you set (e.g. 90%).
+
+The math, so the user sizes the plan honestly: **snapshots ≈ stories × modes ×
+builds.** One `/sync-figma-tokens` PR re-snapshots the *entire* suite × every mode
+in a single build — e.g. 40 components × 2 modes = 80 snapshots per build, and a
+handful of token PRs plus daily `main` builds clears a free tier in a week.
+
+So the guardrails, all of them user-controlled (Chromatic will not cap you):
+
+1. **Set usage alerts** at ~80% on a paid plan so the bill cannot sneak up. On the
+   free plan, make sure the user knows testing *pauses* at the ceiling.
+2. **Scope the CI trigger.** Run Chromatic on **pull requests and `main` only** —
+   never on every branch push — path-filter out docs-only changes, and keep it to
+   one Chromatic build per commit (no duplicate runs).
+3. **Size the plan to the math** before the first token PR. A large story count is
+   also the *only* reason to revisit TurboSnap (see above), and even then treat
+   every token change as a full run.
+
+Do not silently pick a plan or leave the trigger wide open. Name the tradeoff and
+let the user choose with the numbers in front of them.
+
 ## Step 5 — Code Connect (plan-gated, skip gracefully)
 
 Code Connect ties Figma components to their code counterparts so Figma's dev
@@ -174,6 +222,32 @@ mode shows the real code. It's plan-gated (Figma Organization/Enterprise).
   run after the user publishes. This does **not** block the code side: implement
   each slot prop from the recorded slot contract regardless of the Figma dropdown.
 
+## Step 5.5 — Render documentation to code
+
+For each component that has a canonical record
+(`design-system/docs/components/<Name>.doc.json`), render the code-side surfaces
+from it (read `.throughline/references/component-doc-schema.md` for the
+projection contract):
+
+- **Storybook autodocs (MDX).** Generate `<Name>.mdx` next to the component (e.g.
+  `packages/ui/src/<Name>/<Name>.mdx`) rendering summary, description,
+  when-to-use/not, do's/don'ts, accessibility, and a variant/state table. Put the
+  record's fingerprint in MDX frontmatter as `docFingerprint: <fp>`.
+- **JSDoc.** Add a doc comment to the code component from `summary` + `description`
+  and per-prop descriptions from `variants`/`states` meanings, so `argTypes`
+  descriptions surface in the Storybook controls table.
+- **AI digest.** Run `docs:digest` to (re)generate `design-system/docs/index.json`
+  + `design-system/docs/llms.txt` from all records.
+
+**Update the manifest:** add the `storybookMdx` surface to
+`components.meta[<Name>].doc.surfaces` as `{ src: <fp>, render: <hash of the MDX
+file>, file: "<repo-relative MDX path>" }`.
+
+**Wire the gate.** Ensure `docs:check` is part of the repo's verification (a CI
+step and/or a Turbo task). It compares every surface against its record and exits
+non-zero on drift; Figma surfaces report `edit-unverified` (checked live in a Figma
+session). Run `docs:check` once here and confirm it passes before handing off.
+
 ## Step 6 — Finalize component status (Figma write-back)
 
 A component built and storied here is now **done** — but its Figma doc card was
@@ -197,10 +271,15 @@ the `figma_execute` scripting gotchas — `getNodeByIdAsync` and an explicit
 
 - Set `components.meta[name].status` = `"stable"` and refresh
   `components.meta[name].updatedAt` to today.
+- When promoting status (e.g. draft → stable), also set `status` + `updatedAt` in
+  the component's `.doc.json`, recompute its fingerprint, re-run `docs:digest`, and
+  re-render the affected surfaces so `docs:check` stays green.
 - If Figma is connected (per `figma.mechanism`), open the component's doc card and
   update the `Status Label` text to `stable`, re-bind the `Status` chip fill to
-  the **success** semantic color variable (mode-aware, not a hardcoded hex), and
-  set `Last Updated` to today's date — then screenshot to confirm the chip
+  the **success** semantic color variable (mode-aware, not a hardcoded hex), then
+  re-run the canonical doc-card builder against the same card to refresh the
+  header date from the `record.updatedAt` already set above (it locates the date
+  node under either header shape) — then screenshot to confirm the chip
   recolored and the date changed.
 - If Figma isn't connected, still update the manifest and tell the user the card
   will reconcile next Figma session (or offer to reconnect and fix it now).
@@ -261,6 +340,9 @@ that may not exist.
 - Never rely on TurboSnap (`onlyChanged: true`) for a token-driven design system
   — its incremental model keeps missing global token changes. Default to full
   snapshots (every story, every run); revisit only at large story counts.
+- Never leave Chromatic's cost shape unspoken or the CI trigger wide open — there
+  is no hard spend cap on paid plans, so set usage alerts, run it on PRs + `main`
+  only, and size the plan to stories × modes × builds before the first token PR.
 - Never use the sequential model for story-gen — parallelize via subagents.
 - Never capture the Chromatic baseline *after* a code retrofit — baseline before, so
   intended drift-fixes are distinguishable from regressions.

package/adapters/cursor/.cursor/rules/token-builder.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Build a two-tier (primitive + semantic) design token system as Figma variables — color ramps, spacing, type scale, radius, shadows — with light/dark or brand modes. IMPORTANT: this uses ONE COLLECTION PER CATEGORY PER TIER, never one giant Primitives collection + one giant Semantic collection. Each category (color, spacing, type, radius, border) gets its own primitive collection and its own semantic collection so that mode axes (Light/Dark, Desktop/Mobile) belong only to the categories that need them. Use this when the user wants to create design tokens, design variables, a color system, a type scale, a spacing system, or 'build my tokens' in Figma. Also trigger when the user mentions primitives and semantic tokens, variable collections, design system foundations, or modes/themes in Figma."
+description: "Build a two-tier (primitive + semantic) design token system as Figma variables — color ramps, spacing, type scale, radius, shadows — with light/dark or brand modes, using one collection per category per tier. Use this when the user wants to create design tokens, design variables, a color system, a type scale, a spacing system, or 'build my tokens' in Figma. Also trigger when the user mentions primitives and semantic tokens, variable collections, design system foundations, or modes/themes in Figma."
 alwaysApply: false
 ---
 # Token builder

package/adapters/cursor/.cursor/rules/token-crosswalk-builder.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Build the brownfield token crosswalk — a persistent three-way map between each new token, the old Figma variable, and the old code identifier(s) — as crosswalk.json, then install the vetted validator/reverse-index scripts into the monorepo and wire the tokens:validate CI gate. Use this when retrofitting a design system onto a mature codebase, when the user wants to map old tokens to new ones, build a crosswalk, set up tokens:validate, or generate a reverse index for SCSS/Tailwind swaps. Also trigger when retrofit-planner reaches the crosswalk stage, or after design-system-audit has sized the retrofit. Make sure to use this whenever someone needs the machine-readable backbone that drives a brownfield code retrofit and its validation gate."
+description: "Build the brownfield token crosswalk — a persistent three-way map between each new token, the old Figma variable, and the old code identifier(s) — then wire the tokens:validate CI gate. Use this when retrofitting a design system onto a mature codebase, when the user wants to map old tokens to new ones, build a crosswalk, set up tokens:validate, or generate a reverse index for SCSS/Tailwind swaps. Also trigger when retrofit-planner reaches the crosswalk stage, or after design-system-audit has sized the retrofit."
 alwaysApply: false
 ---
 # Token crosswalk builder

package/adapters/cursor/.cursor/rules/token-sheet-builder.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Build a beautiful, on-brand \"Foundations\" page in Figma that visually documents every variable collection and style — color ramps with swatches, the type scale, spacing, radius, shadows/elevations — with swatches live-bound to the actual variables where Figma allows. Use this when the user wants a visual stylesheet, a token reference page, a Foundations page, to document or showcase their design system, or to \"see all my tokens\" laid out. Also trigger after token-builder completes, when the user wants a visual artifact of their tokens. Make sure to use this when someone wants their tokens presented visually rather than just existing as variables."
+description: "Build an on-brand \"Foundations\" page in Figma that visually documents every variable collection and style — color ramps with swatches, the type scale, spacing, radius, shadows/elevations. Use this when the user wants a visual stylesheet, a token reference page, a Foundations page, to document or showcase their design system, or to \"see all my tokens\" laid out. Also trigger after token-builder completes, when the user wants a visual artifact of their tokens."
 alwaysApply: false
 ---
 # Token sheet builder

package/adapters/cursor/.cursor/rules/token-sync-layer.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Sync Figma design variables into code-ready token files by extracting them to DTCG-format JSON, running them through Style Dictionary, and emitting framework-specific outputs via per-platform adapters (shadcn/Tailwind, MUI, vanilla CSS, iOS Swift, Android Kotlin, or custom). Sets up the reusable \"sync figma tokens\" command that re-runs the pipeline to catch updates and opens a PR for review. Use this when the user wants to turn Figma tokens into code, sync design tokens, generate tokens.css or a Tailwind config or tokens.swift, set up a token pipeline, or run \"sync figma tokens\". Also trigger when the user mentions Style Dictionary, design token export, or keeping code in sync with Figma. Make sure to use this whenever someone wants their Figma variables reflected in actual code files."
+description: "Sync Figma design variables into code-ready token files via DTCG JSON and Style Dictionary, emitting framework-specific outputs (shadcn/Tailwind, MUI, vanilla CSS, iOS Swift, Android Kotlin, or custom), and set up the reusable \"sync figma tokens\" command. Use this when the user wants to turn Figma tokens into code, sync design tokens, generate tokens.css or a Tailwind config or tokens.swift, set up a token pipeline, or run \"sync figma tokens\". Also trigger when the user mentions Style Dictionary, design token export, or keeping code in sync with Figma."
 alwaysApply: false
 ---
 # Token sync layer

package/adapters/generic/AGENTS.md

@@ -4,22 +4,23 @@ ThroughLine builds a design system end to end. Read the matching skill file for
 
 ## ThroughLine skills
 
-- `component-builder` — Build a foundational set of Figma components — buttons, inputs, cards, badges, chips, modals, and more — as properly structured components with variant matrices (types, sizes, states) and icon/component/content slots, bound to the design system's tokens and styles. → read `skills/component-builder/SKILL.md`.
+- `component-builder` — Build Figma components — buttons, inputs, cards, badges, chips, modals, and more — with variant matrices (types, sizes, states) and icon/component/content slots bound to the design system's tokens and styles. → read `skills/component-builder/SKILL.md`.
 - `component-pipeline` — Take a single new component from Figma to fully-built-and-storied code, end to end — build it in Figma, sync any new tokens it introduced, then build its code component and stories. → read `skills/component-pipeline/SKILL.md`.
-- `design-system-audit` — Measure a pre-existing design system before retrofitting it onto tokens — size the code-side color surface and inventory the existing Figma file with verified per-class reads, then compute how semantic the system already is so the retrofit is right-sized. → read `skills/design-system-audit/SKILL.md`.
+- `design-system-audit` — Measure a pre-existing design system before retrofitting it onto tokens, so the retrofit is right-sized. → read `skills/design-system-audit/SKILL.md`.
 - `figma-environment-setup` — Set up the local working folder and connect the agent to Figma so the design-system skills can read and write variables, styles, and components. → read `skills/figma-environment-setup/SKILL.md`.
-- `icon-system-builder` — Build an icon system in Figma — a dedicated "Icons" page populated with the user's chosen icon library (Lucide, Material, or custom SVGs) as well-named, scalable components — using the fastest, most-automated mechanism per library (for Lucide, batch-fetching the curated subset's official SVGs from the source repo and componentizing them hands-off; for Material, the official community file or importer plugin) rather than hand-generating icons or making the user copy components by hand. → read `skills/icon-system-builder/SKILL.md`.
-- `repository-builder` — Graduate the local design-system folder into a real monorepo — a pnpm + Turborepo workspace with packages for tokens and UI components and room for apps — and walk the user from a plain folder to local git to a GitHub remote with PRs and CI. → read `skills/repository-builder/SKILL.md`.
-- `retrofit-planner` — Orchestrate a full brownfield design-system retrofit end to end — audit, refine variables in place, rebind components, sync, capture a Chromatic baseline, retrofit the code with dual output, then remove the old tokens only after a zero-reference grep — with a human confirmation gate between every phase. → read `skills/retrofit-planner/SKILL.md`.
-- `storybook-chromatic-builder` — Stand up Storybook in the monorepo, build code components matching the Figma design system (consuming the synced tokens and implementing the captured slot contracts), generate stories for every component, set up Chromatic for visual regression testing, and wire Code Connect when the user's Figma plan supports it. → read `skills/storybook-chromatic-builder/SKILL.md`.
-- `token-builder` — Build a two-tier (primitive + semantic) design token system as Figma variables — color ramps, spacing, type scale, radius, shadows — with light/dark or brand modes. → read `skills/token-builder/SKILL.md`.
-- `token-crosswalk-builder` — Build the brownfield token crosswalk — a persistent three-way map between each new token, the old Figma variable, and the old code identifier(s) — as crosswalk.json, then install the vetted validator/reverse-index scripts into the monorepo and wire the tokens:validate CI gate. → read `skills/token-crosswalk-builder/SKILL.md`.
-- `token-sheet-builder` — Build a beautiful, on-brand "Foundations" page in Figma that visually documents every variable collection and style — color ramps with swatches, the type scale, spacing, radius, shadows/elevations — with swatches live-bound to the actual variables where Figma allows. → read `skills/token-sheet-builder/SKILL.md`.
-- `token-sync-layer` — Sync Figma design variables into code-ready token files by extracting them to DTCG-format JSON, running them through Style Dictionary, and emitting framework-specific outputs via per-platform adapters (shadcn/Tailwind, MUI, vanilla CSS, iOS Swift, Android Kotlin, or custom). → read `skills/token-sync-layer/SKILL.md`.
+- `icon-system-builder` — Build an icon system in Figma — a dedicated "Icons" page of well-named, scalable icon components from Lucide, Tabler, Phosphor, Material, or custom SVGs. → read `skills/icon-system-builder/SKILL.md`.
+- `repository-builder` — Graduate the local design-system folder into a real monorepo — a pnpm + Turborepo workspace with packages for tokens and UI components — and walk the user from a plain folder to local git to a GitHub remote with PRs and CI. → read `skills/repository-builder/SKILL.md`.
+- `retrofit-planner` — Orchestrate a full brownfield design-system retrofit end to end — audit, refine, rebind, sync, baseline, code, docs, cleanup — with a human confirmation gate between every phase. → read `skills/retrofit-planner/SKILL.md`.
+- `storybook-chromatic-builder` — Stand up Storybook in the monorepo, build code components matching the Figma design system, generate stories for every component, set up Chromatic for visual regression testing, and wire Code Connect when the user's Figma plan supports it. → read `skills/storybook-chromatic-builder/SKILL.md`.
+- `token-builder` — Build a two-tier (primitive + semantic) design token system as Figma variables — color ramps, spacing, type scale, radius, shadows — with light/dark or brand modes, using one collection per category per tier. → read `skills/token-builder/SKILL.md`.
+- `token-crosswalk-builder` — Build the brownfield token crosswalk — a persistent three-way map between each new token, the old Figma variable, and the old code identifier(s) — then wire the tokens:validate CI gate. → read `skills/token-crosswalk-builder/SKILL.md`.
+- `token-sheet-builder` — Build an on-brand "Foundations" page in Figma that visually documents every variable collection and style — color ramps with swatches, the type scale, spacing, radius, shadows/elevations. → read `skills/token-sheet-builder/SKILL.md`.
+- `token-sync-layer` — Sync Figma design variables into code-ready token files via DTCG JSON and Style Dictionary, emitting framework-specific outputs (shadcn/Tailwind, MUI, vanilla CSS, iOS Swift, Android Kotlin, or custom), and set up the reusable "sync figma tokens" command. → read `skills/token-sync-layer/SKILL.md`.
 
 ## ThroughLine commands
 
 - `design-system-status` — Show a plain-language summary of the current design system state — what's set up, what's not, and sensible next steps — read from design-system.json. → read `commands/design-system-status.md`.
+- `document-component` — Author, refresh, or reconcile the usage documentation for one existing component — draft its canonical doc record from four sources, project it to Figma, the doc card, and code, and resolve any drift via a reviewable per-item choice. → read `commands/document-component.md`.
 - `new-component` — Build a single new component end to end — in Figma, then sync any new tokens, then build its code component and stories — with a confirmation between each stage. → read `commands/new-component.md`.
 - `start` — Start building your design system — the deterministic entry point. → read `commands/start.md`.
 - `sync-figma-tokens` — Re-run the Figma-to-code token sync — extract current Figma variables, rebuild code outputs via Style Dictionary, and open a PR with the changes for review. → read `commands/sync-figma-tokens.md`.

package/adapters/generic/commands/document-component.md

@@ -0,0 +1,58 @@
+Document a single existing component end to end, using the settings already in
+`design-system.json` (`project.uiFramework`, `figma.mechanism`, `sync.platforms`)
+rather than re-asking configuration. Scale explanation to `user.codingLevel`.
+
+Ask which component to document (e.g. "Button"), then:
+
+1. **Author/refresh the record.** Run the doc-authoring pipeline from
+   the `component-builder` skill's *Author the documentation record* step —
+   ingest any existing docs first (brownfield), then infer → enrich (from
+   `.throughline/references/component-doc-archetypes.md`) → specialize →
+   interview. Authored prose follows
+   `.throughline/references/doc-writing-standard.md`. Set `updatedAt` to
+   today's date (ISO, `YYYY-MM-DD`) whenever the record is written or rewritten —
+   it is a projected field and the doc card's header renders it. Once the record is
+   written, run `node .throughline/scripts/docs-lint.mjs
+   design-system/docs/components/<Name>.doc.json` and fix its warnings. Do not
+   raise a separate confirmation for a warning on an `imported`/`user` block:
+   draft the rewrite and carry it into the approval gate below, shown as
+   before/after and labelled with the block's provenance, so one approval covers
+   the whole record. The user approves the drafted record before anything is
+   projected (Figma description, doc card, manifest). Blocks the user did not
+   clear keep their existing text; blocks the user did clear are stamped
+   `imported+user` so a later run neither re-asks nor rewrites them.
+2. **Project it.** Write `design-system/docs/components/<Name>.doc.json`, set the
+   Figma component `description`, rebuild the doc card's `Usage` band with the
+   canonical builder (`.throughline/references/doc-card-builder.md` —
+   verify its returned summary and stamp `surfaces.docCard.{src,render,renderer}`
+   from it), and (if the repo/code side exists) render MDX/JSDoc and run
+   `docs:digest` per the `storybook-chromatic-builder` render step.
+3. **Reconcile drift.** Before trusting `docs:check`, confirm the repo's copy of
+   the doc scripts is current: compare `DOC_CARD_RENDERER_VERSION` in the repo's
+   `scripts/lib/doc-card-plan.mjs` against the same constant in
+   `.throughline/scripts/lib/doc-card-plan.mjs`. If the repo file is
+   missing, or its version is lower, `docs:check` is reading stale rules and its
+   "no drift" is meaningless — say so plainly, and offer to refresh the repo's
+   doc scripts from the plugin copy. Refresh the whole set and re-check the npm
+   registrations, both per **Documentation scripts — install as a set** in
+   `.throughline/scripts/README.md` — a refreshed file whose script was
+   never registered is the same failure in a new place. Run `docs:check` (with the
+   refreshed scripts, if any). For each drifted surface, offer a per-item
+   choice — **re-render** (canonical wins) or **pull-back**
+   (fold the surface edit into the record) — and land the result as a reviewable
+   change. On a brownfield component's first pass, adopt existing content
+   (`provenance: imported`) rather than overwriting it.
+   `docs:check` may also report `layout-upgrade-available` (informational, never
+   failing): the card's layout predates the current builder. Offer to re-render
+   the `Usage` band now — rebuild happens on this touch, never unprompted.
+4. **Close the flow.** Hand back in the four-beat guide voice from
+   `.throughline/references/guide-voice.md`: the outcome, what you set
+   aside and why, one recommended next step, and at most one light alternative.
+   Read existing state to name what is actually outstanding rather than guessing —
+   a component at `status: "draft"` with no code surface in `meta[name].doc.surfaces`
+   means the code side is deferred. Do not close with a grid of co-equal options.
+
+See `.throughline/references/component-doc-schema.md` for the record schema,
+fingerprint contract, and projection mapping. If a component was never built in
+Figma, point the user at `component-builder` first.
+

package/adapters/generic/skills/component-builder/SKILL.md

@@ -227,6 +227,110 @@ Two rules for every slot:
 Record each component's slots, variant matrix, and token bindings in the
 component spec (for Code Connect when available, else the repo component spec).
 
+## Step 4.5 — Author the documentation record (and project it)
+
+Every component gets a canonical documentation record — the source of truth for
+its usage docs — written to the working folder next to `design-system.json`
+(**folder-resident from day one**, exactly like the manifest; no repo required).
+Read `.throughline/references/component-doc-schema.md` for the exact JSON
+schema, the fingerprint algorithm, and the projection contract.
+
+**Run the generation pipeline (each layer only fills what it legitimately knows;
+stamp `provenance` per block):** all authored prose follows
+`.throughline/references/doc-writing-standard.md` — its plain
+reference register, not this skill's guide voice.
+
+0. **Ingest existing docs — brownfield only, runs first.** If docs already exist
+   for this component (code JSDoc/MDX/README, or a populated Figma component
+   `description`), read them and seed the record marked `provenance: imported`.
+   **Never silently overwrite existing human-written docs** — this is the
+   read-before-you-assert rule. Skip on greenfield.
+1. **Infer from the built artifact.** From the component you just built — its
+   variants, states, slots, and bound tokens — author `description`, `variants`,
+   `states`, and `tokensUsed` (`tokensUsed` comes from the real variable bindings,
+   not a guess). Provenance `ai-inferred`.
+2. **Enrich from the archetype knowledge base.** Match the component to the nearest
+   archetype in `.throughline/references/component-doc-archetypes.md` and
+   seed `dos`, `donts`, `accessibility`, `whenToUse`, `whenNotToUse`. Provenance
+   `best-practice` (or `w3c-apg` for the accessibility block).
+3. **Specialize to `project.uiFramework`.** Align variant-meaning wording and the
+   accessibility idiom to the target framework (the same field you read for variant
+   vocabulary). Provenance `framework`.
+4. **Interview for the non-inferable.** Ask the user for brand/product-specific
+   do's & don'ts and intent. Provenance `user`. Write the draft to
+   `design-system/docs/components/<Name>.doc.json`, run
+   `node .throughline/scripts/docs-lint.mjs design-system/docs/components/<Name>.doc.json`,
+   and fix the warnings it raises. Do not raise a separate confirmation for
+   a warning on an `imported`/`user` block: draft the rewrite and carry it
+   into the approval gate below, shown as before/after and labelled with the
+   block's provenance. **Show the whole drafted record and get explicit
+   approval before projecting it anywhere** (Figma description, doc card,
+   manifest) — one approval covers the whole record. Blocks the user did not
+   clear keep their existing text; blocks the user did clear are stamped
+   `imported+user` so a later run neither re-asks nor rewrites them.
+
+**Write the record and project it:**
+
+- Write `design-system/docs/components/<Name>.doc.json` (JSON; required fields
+  `name`, `summary`, `description`).
+- **Figma component description.** Set the component's native `description` field
+  (via `figma_set_description`) from this exact template — this is the surface
+  Dev Mode and Code Connect read, and it must be reproducible byte-for-byte by
+  any agent from the same record:
+
+  ```
+  <summary>
+
+  **When to use**
+  - <whenToUse[n]>
+
+  **When not to use**
+  - <whenNotToUse[n]>
+
+  **Do**
+  - <dos[n]>
+
+  **Don't**
+  - <donts[n]>
+
+  **Accessibility**
+  - <accessibility.keyboard[n]>
+  - <accessibility.notes[n]>
+
+  <!-- tl:doc <fp> -->
+  ```
+
+  Rules: every line is a record string **verbatim** — no re-wording, no added
+  connectives, no sentences that appear nowhere in the record. A block whose
+  source array is empty is omitted along with its bold label. The **Accessibility**
+  label is omitted only when both `accessibility.keyboard` and `accessibility.notes`
+  are empty; when one is empty its bullets are simply absent and the label stays.
+  Sections are separated by exactly one blank line, and the fingerprint marker is
+  always last.
+- **Doc card body.** Render the card's `Usage` band with the canonical builder
+  snippet in `.throughline/references/doc-card-builder.md` (via
+  `figma_execute` with an explicit `timeout`, one card per call): fill the
+  RECORD/CANONICAL_FP slots, resolve the nine required semantic variables and
+  the `Body/Default` text style per that file's call contract, run it, and
+  verify the returned summary (`rowsRendered`, `blocksCreated`, `cardWidth`) —
+  not a screenshot. The builder creates the `Doc Fingerprint` node itself and
+  is the only thing that may build the usage body — never hand-assemble it.
+- Compute `<fp>` as the canonical fingerprint defined in the schema reference
+  (sha256 of the projected record without `provenance`, first 16 hex chars).
+
+**Update the manifest (fields this skill owns):** set
+`components.meta[<Name>].doc` to `{ path, fingerprint: <fp>, surfaces: {
+figmaDescription: { src: <fp>, render: <hash of the description text> }, docCard: {
+src: <fp>, render: <summary.renderHash>, renderer: <summary.rendererVersion> } } }`
+— the docCard entry is stamped from the builder's returned summary, never by
+re-reading the card. The code surfaces (`storybookMdx`) are added later by
+`storybook-chromatic-builder`.
+
+Run the standard doc-card visual-validation + post-build audit
+(`.throughline/references/figma-component-standards.md`) after enriching
+the card. `docs:check` runs at the code stage; at folder stage the record + Figma
+surfaces are the fallback.
+
 ## Step 5 — Naming as contract
 
 Name components deterministically so Figma↔code mapping is automatic: `Button` ↔
@@ -284,4 +388,7 @@ Offer next steps: build the code counterparts and stories
   internal architecture) **detaches every instance** that referenced its variants (the
   Card's footer buttons, etc.). Record which components consume which, warn before an
   architectural rebuild, and re-instance the affected consumers afterward.
+- Never overwrite an existing component `description` or imported doc content
+  without reading it first and marking it `provenance: imported` — brownfield docs
+  are seeds, not blank slates.
 

package/adapters/generic/skills/design-system-audit/SKILL.md

@@ -56,6 +56,23 @@ counts:
 repo with no Tailwind simply scores `0` there. Detect what the repo actually uses (is
 there a `tailwind.config`? SCSS? CSS-in-JS?) and explain the counts in those terms.
 
+## Step 1.5 — Size the documentation surface
+
+Inventory existing documentation the same way the code surface is sized — from
+**verified reads, never assumptions**. Per component (or per code component when no
+Figma component exists yet), record whether usage docs already exist and where:
+
+- **Code:** JSDoc/TSDoc on the component, an `.mdx` doc page, a per-component
+  README.
+- **Figma:** a populated component `description` field.
+
+Write the totals to `audit.docSurface` in the manifest, e.g. `{ "documented": 12,
+"undocumented": 34, "sources": { "codeJsdoc": 8, "mdx": 4, "figmaDescription": 6,
+"readme": 3 } }`. This right-sizes the documentation retrofit (how much exists to
+adopt vs. author from scratch) so `retrofit-planner`'s `docs` phase can be planned
+against real numbers. See `.throughline/references/component-doc-schema.md`
+for what a full record contains.
+
 ## Step 2 — Inventory the Figma file (verified per-class reads)
 
 Variables, text styles, and effect/paint styles are **different surfaces** — read each
@@ -103,6 +120,9 @@ Set `tokens.intakeMode: "retrofit"` (this skill establishes the brownfield path
 owns this transition). Append `design-system-audit` to `completedSkills`.
 
 Then recommend the next step:
+- Report the documentation debt from `audit.docSurface` (documented vs.
+  undocumented) and note that the retrofit's `docs` phase will adopt existing docs
+  before authoring the gaps.
 - If the user wants the guided, gated end-to-end retrofit → **`retrofit-planner`**
   (the orchestrator; recommended for multi-session retrofits).
 - If they only want the crosswalk backbone next → **`token-crosswalk-builder`** (it

package/adapters/generic/skills/repository-builder/SKILL.md

@@ -106,6 +106,20 @@ in it" — they already have a working local repo.
 On success, set `workspace.stage` and `repo.stage` to `github` and record
 `repo.remote`. Append `repository-builder` to `completedSkills`.
 
+### Adopt the documentation store
+
+The folder-resident documentation store at `design-system/docs/` (canonical
+`*.doc.json` records plus the generated `index.json` + `llms.txt`) already exists
+from the Figma phase. Bring it under version control as-is — **do not relocate it**
+(the path is stable across folder→repo, and every manifest `doc.path` points at it).
+Ensure it is committed (not git-ignored).
+
+Wire the documentation drift gate into the repo's verification so it runs in CI
+alongside `tokens:validate`: add a `docs:check` step (the `docs-check.mjs` script is
+installed by `storybook-chromatic-builder`; if code hasn't been set up yet, note
+that the gate comes online with the Storybook step). `docs:check` exits non-zero on
+drift; Figma surfaces report `edit-unverified` and are checked in a Figma session.
+
 ## Secrets: the part most people have never done
 
 This is where users with low coding experience get stuck — many have never made