token-crosswalk-builder
Skill80 starsChanged 32 days agoMITView on GitHub
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.
In this repository11 other files it gives its agents.
- component-builderSkill
- component-pipelineSkill
- design-system-auditSkill
- figma-environment-setupSkill
- icon-system-builderSkill
- repository-builderSkill
- retrofit-plannerSkill
- storybook-chromatic-builderSkill
- token-builderSkill
- token-sheet-builderSkill
- token-sync-layerSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 4 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 21
Read user.codingLevel (${CLAUDE_PLUGIN_ROOT}/references/coding-level.md) and scale explanation accordingly.
- Distinctive: line 28
Read the manifest. This skill needs:
- Very specific: line 47
Write packages/tokens/crosswalk.json per the contract in ${CLAUDE_PLUGIN_ROOT}/references/crosswalk-schema.md.
- Very specific: line 64
Do not guess values. Every newValue comes from a read of the DTCG source, not an assumption (read discipline).
- Very specific: line 94
Run npm run tokens:validate (from packages/tokens/).
- Very specific: line 103
Run npm run tokens:reverse-index.
- Very specific: line 110
Write the tokenCrosswalk section only (this skill owns it.
- Distinctive: line 122
Never delete old tokens or outputs here — that's the cleanup phase, gated by the token-removal guard returning zero references (safe …
- Distinctive: line 124
Never edit generated token files to make the validator pass — fix the source.
- Very specific: line 125
Never write another skill's manifest fields (e.g.
- Very specific: line 127
Never proceed past a red tokens:validate.
- Distinctive: line 128
Never assert a prerequisite is absent without a verified read (read discipline).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Token crosswalk builder
Builds the backbone artifact of a brownfield retrofit: crosswalk.json, a
persistent three-way map of new token ↔ old Figma variable ↔ old code identifier.
It drives the code retrofit and the tokens:validate CI gate. This skill also
installs the canonical scripts into the user's repo and wires the gate.
This is a brownfield skill. Before doing anything, read
${CLAUDE_PLUGIN_ROOT}/references/brownfield-retrofit.md (read discipline, the 7
guardrails, the safe sequence) and
${CLAUDE_PLUGIN_ROOT}/references/crosswalk-schema.md (the exact contract). Greenfield
builds don't need this skill.
Calibrate
Read user.codingLevel (${CLAUDE_PLUGIN_ROOT}/references/coding-level.md) and scale
explanation accordingly. The crosswalk involves JSON, npm scripts, and a CI gate — for
new users explain each plainly the first time; for comfortable users be terse.
Actions are identical across levels.
Prerequisites (offer to run them, don't bail)
Read the manifest. This skill needs:
- A DTCG token source at
packages/tokens/dtcg/tokens.json— the validator resolves against it. If it doesn't exist, offer to runtoken-sync-layerfirst (it emits this file). Apply the read discipline: confirm the file exists by reading it, never assume it's absent without looking. - The audit inputs — ideally the
auditmanifest section (code surface, Figma inventory,percentSemantic) populated bydesign-system-audit. Ifauditis present, use it to seed the rows. If it isnull(audit hasn't run — it lands in Plan 3), don't block: ask the user for the old→new mapping inputs directly (which old Figma variables and code symbols map to which new tokens), and proceed. Note plainly that runningdesign-system-auditfirst would pre-fill this. - A repo at
local-gitorgithub(workspace.stage) so the installed scripts andpackage.jsonchanges land as a reviewable diff/PR. If stillfolder, offerrepository-builder.
Step 1 — Build crosswalk.json
Write packages/tokens/crosswalk.json per the contract in
${CLAUDE_PLUGIN_ROOT}/references/crosswalk-schema.md. One row per new token:
newToken— the DTCG dot-path exactly as it appears inpackages/tokens/dtcg/tokens.json(e.g.color.text.primary).newValue— the resolved leaf value (follow{…}aliases to the literal).tier—primitiveorsemantic.figmaOld— the old Figma variable name/path, ornullif newly added.codeTokens[]— the old code identifiers this token replaces ($primary-red,bg-primary-red,Colors.primaryRed,--primary-red). May be[].status—aligned | renamed | drift-fix | added | mapped-nearest. Assign by: same name & value →aligned; same value, new name →renamed; value intentionally changed →drift-fix; brand-new token →added; no exact old equivalent, mapped to nearest →mapped-nearest.recommendedSemantic— optional semantic target for a raw/primitive usage, elsenull.
Do not guess values. Every newValue comes from a read of the DTCG source, not an
assumption (read discipline).
Step 2 — Install the vetted scripts + wire tokens:validate
Copy these from ${CLAUDE_PLUGIN_ROOT}/scripts/ into the user's repo verbatim
(they are zero-dependency and version with the user's repo so their CI can run them):
lib/crosswalk.mjs→packages/tokens/scripts/lib/crosswalk.mjslib/dtcg.mjs→packages/tokens/scripts/lib/dtcg.mjs(required byvalidate-crosswalk.mjs— copying the validator without it breaks the gate at import)lib/source-scan.mjs→packages/tokens/scripts/lib/source-scan.mjs(required byguard-token-removal.mjs— copying the guard without it breaks it at import)validate-crosswalk.mjs→packages/tokens/scripts/validate-crosswalk.mjsbuild-reverse-index.mjs→packages/tokens/scripts/build-reverse-index.mjsguard-token-removal.mjs→packages/tokens/scripts/guard-token-removal.mjscrosswalk.schema.json→packages/tokens/crosswalk.schema.json(besidecrosswalk.json, so the$schemapointer resolves)
Then add to packages/tokens/package.json scripts (don't clobber existing keys):
"tokens:validate": "node scripts/validate-crosswalk.mjs --crosswalk crosswalk.json --tokens dtcg/tokens.json",
"tokens:reverse-index": "node scripts/build-reverse-index.mjs --crosswalk crosswalk.json --out crosswalk.reverse.json"See ${CLAUDE_PLUGIN_ROOT}/scripts/README.md for the full install contract.
Step 3 — Run the gate (must pass N/N)
Run npm run tokens:validate (from packages/tokens/). It must report N/N —
every row's resolved value matches its newValue. If it reports mismatches or
missing tokens, fix the crosswalk (or the token source) and re-run. Never proceed
on a red validator and never edit a generated token file to make it pass — change
the source in Figma and re-sync (guardrail 7). The validator is the source of truth
that the crosswalk and the real tokens agree.
Step 4 — Generate the reverse index
Run npm run tokens:reverse-index. This writes crosswalk.reverse.json
(codeToken → newToken), which the code-retrofit phase uses to semi-automate the
SCSS/Tailwind swaps. If it reports conflicts (one old symbol mapping to two new
tokens), resolve them in the crosswalk before relying on the index.
Step 5 — Update the manifest
Write the tokenCrosswalk section only (this skill owns it; never write another
skill's fields):
path— the actual path written ("packages/tokens/crosswalk.json").statusCounts— copy the camelCase object the validator printed ({ aligned, renamed, driftFix, added, mappedNearest }).validatorPassing—trueoncetokens:validatepasses N/N.
Append token-crosswalk-builder to completedSkills.
What this skill must NOT do
- Never delete old tokens or outputs here — that's the cleanup phase, gated by the token-removal guard returning zero references (safe sequence, guardrail 4).
- Never edit generated token files to make the validator pass — fix the source.
- Never write another skill's manifest fields (e.g.
tokens.intakeModeis owned bydesign-system-audit). - Never proceed past a red
tokens:validate. - Never assert a prerequisite is absent without a verified read (read discipline).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

