token-mapping

token-mapping is a read-only report. It finds the hardcoded style values on a page, file or diff and lands each one on your existing design tokens by what the value does, so an 8px radius never stands in for an 8px gap. It never edits.

Use to report how hardcoded style values on a page, file or diff map onto a project's existing design tokens, such as "are we using our tokens here", "which hardcoded colors map to which tokens", a token audit or planning a token migration. It never edits. Replacing the values is build-design-system.

1. Finds your token list: token files, theme entries, custom properties on :root. A framework's default theme is not your list.
2. Finds the values: what you named, else the branch diff, else the product code, each with its file, line, property and job.
3. Resolves every alias to its final value in each mode.
4. Normalises both sides with code, lengths to px and colors to OKLCH compared by delta E, never by eye.
5. Classifies each row: exact, semantic (inside tolerance, with the difference in numbers), ambiguous (with every candidate) or gap.

A report with Summary, Mapping, Do not use, Ambiguous, Gaps, For a person to decide and Source, ending in a Coverage: line. When gaps are over 30% of rows and number 12 or more, it leads with "Status: not actionable", because the token list is usually the wrong one.

• Match on value before purpose. Text set in #6b7280 never maps to a border token just because the hex is equal.
• Fill a token list from memory.
• Change a file. git status is the same before and after.

token-mapping installs with the other five design.how skills, for Claude Code, Cursor, Codex and any agent that reads Agent Skills. The install command and the .zip are on Skills, free after an email signup.

• design-system-boss: Say what is wrong with your UI in plain words; it picks a playbook and runs the other design.how skills in order.
• build-design-system: Builds a design system from the UI your app already ships: tokens, components, docs and checks, proved on one flow.
• migrate-design-system: Moves every screen of an app onto an existing design system with many agents, each screen checked against its before screenshot.
• ui-review: Reviews a screen, flow or running build, accessibility included, and ranks what is broken with evidence.
• component-docs: Writes one component's documentation from its code and two real uses, with rules next to the examples.