Skip to content
Skillpedia
Interfaces (UI/UX)101k · #530

token-map

Lets your agent connect design information with the project's design system. This creates a standard the agent can use to generate the design.

What it does

This program helps organize a design's visual styles (like colors and fonts) so they work well with an existing design system. It compares your design's styles against the styles defined in the design system and creates a map to ensure everything matches consistently.

When to use it

  • ✓When migrating a design from Figma to code.
  • ✓When updating an existing design to use a new design system.
  • ✓When you want to ensure all visual styles (colors, fonts, spacing) are consistent between the design and the design system.

Example of what to ask your AI

“Please map the color and typography tokens from my design to the active design system.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/nexu-io/open-design/blob/main/plugins/_official/atoms/token-map/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/nexu-io/open-design/blob/main/plugins/_official/atoms/token-map/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

The program analyzes the visual styles (tokens) from your design, extracted from Figma or code. It tries to guess the purpose of each style (e.g., if it's a primary color or a heading) based on how it's used in the design. Then, it creates a file showing how each of your design's styles corresponds to a style in the design system.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add nexu-io/open-design --skill token-map

Or download just the file:

curl -L https://raw.githubusercontent.com/nexu-io/open-design/main/plugins/_official/atoms/token-map/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

Token map

Spec §10 / §21.3.1: every figma-migration / code-migration run crosses the same boundary — "the source has its own tokens; the target uses the active OD design system; we need a deterministic mapping". This atom produces that mapping.

Inputs

  • figma/tokens.json from figma-extract (figma-migration), OR
  • code/tokens.json from design-extract (code-migration).
  • The active design system DESIGN.md (already injected into the prompt; the atom reads from the staged design-system context).

Output

project-cwd/
└── token-map/
    ├── colors.json     # { source: '#hex' | 'tokenName', target: '--ds-token' }[]
    ├── typography.json # font + size + weight pairings
    ├── spacing.json    # spacing scale crosswalk
    ├── unmatched.json  # { source: ..., reason: 'no-target-equivalent' }[]
    └── meta.json       # { sourceKind: 'figma' | 'code', generatedAt, atomDigest }

unmatched.json is the audit list a human reviews; the agent must not invent target tokens silently.

Semantic token inference

Figma often exports anonymous source names such as color-3, paint/17, or raw #5B8DEF. Do not ask the user to rename those before mapping. First infer the semantic role from usage evidence:

  • Node path, component name, instance overrides, variant/state labels, frame name, layer name, and nearby text such as Primary, Selected, Link, Error, Focus, Nav, Button, or CTA.
  • CSS-like position in the rendered tree: background fill, foreground text/icon, border, divider, overlay, shadow tint, focus ring, status badge, chart series, or brand/accent treatment.
  • Contrast relationships: a color paired repeatedly with the main canvas is likely foreground; one paired with foreground inside CTA components is likely primary/accent background; a thin outline around interactive elements is likely border or focus-ring.
  • Reuse topology: a value that appears across primary buttons, selected tabs, and active nav items is stronger evidence for --ds-color-primary than a value that appears once in an illustration.

Use that role evidence to choose among existing active design-system tokens and to decide whether an anonymous token should be renamed or left unmatched before the executable mapping pass. Keep the on-disk token-map contract unchanged: the atom still writes the existing bucket files, unmatched.json, and meta.json only.

For example, this is a useful reasoning note for deciding whether color-3 should map to the active primary token:

{
  "source": "color-3",
  "value": "#5B8DEF",
  "role": "primary",
  "targetCandidates": ["--ds-color-primary", "--ds-color-link"],
  "evidence": [
    "Button/Primary fill",
    "Selected tab indicator",
    "Link text in Settings frame"
  ]
}

Then map to an active design-system token only when the evidence is role-based, not value-only. If the top candidates are too close to call, or if the evidence points to conflicting roles (primary vs link vs focus-ring), leave the source token unmatched using the existing no-target-equivalent reason and include the competing candidates in the hint. This keeps automation useful for common anonymous-token cases while preserving human review for ambiguous brand decisions.

Before / after expectation

Without semantic inference, an anonymous Figma token can only produce an uncertain value-level mapping:

{
  "source": "color-3",
  "value": "#5B8DEF",
  "target": null,
  "reason": "no-target-equivalent"
}

With semantic inference, the same token should carry role evidence before it is accepted:

{
  "source": "color-3",
  "value": "#5B8DEF",
  "target": "--ds-color-primary",
  "via": "name"
}

This deterministic v1 atom does not claim a measured accuracy lift by itself. Treat the expected improvement as coverage of previously manual anonymous-token cases when the Figma tree contains enough role evidence. Real accuracy numbers require a fixture suite with known source tokens, expected semantic roles, and a before/after agent run. See examples/semantic-inference-before-after.json for a deterministic same-token-batch simulation that compares the old value-level output with the semantic inference output.

Convergence

The atom completes when every input token is either mapped or explicitly recorded under unmatched.json with a non-empty reason. The until evaluator reads tokens.unmatched.length === 0

…

FAQ

What are 'tokens'?

Tokens are the basic building blocks of a design's visual styles, such as a specific color (e.g., blue #0000FF), a font size (e.g., 16px), or a spacing value (e.g., 8px).

What happens if a style from my design doesn't have an equivalent in the design system?

The program will list these styles in a file called 'unmatched.json', explaining why they couldn't be mapped. This allows you to review and decide what to do with them manually, rather than the program inventing something.

How does the program know which style from my design matches which style in the design system?

It uses clues from the design, such as component names, the context where the style is used (e.g., button text), and color relationships, to infer the style's purpose and find the best match in the design system.

Details

Original description by the author

Map an extracted Figma / source-code token bag onto the active OD design system, producing a deterministic mapping the generate stage can consume.

repo: nexu-io/open-design

Popularity

GitHub stars
101k
Ranking position
#530
License
Apache-2.0
Updated
10/16/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills