Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jpoindexter/design-tokens
Architect, name, format, and export design tokens as the single source of truth across Figma, code, and multi-platform builds using the W3C DTCG format, a primitive→semantic→component tier model, and a Style Dictionary v4 pipeline.
Passed 22 of 22 test cases with the skill, and 21 of 22 without it.
1 fixed21 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
We are standardizing our UI design system inputs into an industry-standard token format so developers and designers can share a unified design definition. Below are some initial visual choices from our team (such as brand blue #0052FF, neutral grays from light to dark, card background colors, primary button padding, and text styles). Please take these decisions and structure them into a W3C DTCG compliant JSON token repository. The output should cleanly organize raw options separately from functional UI intent decisions and component-scoped aliases, using appropriate property types and reference syntax.
| Checked | Without skill | With skill |
|---|---|---|
| The component token definitions route button padding through semantic spatial token references rather than directly referencing primitive spacing tokens. | Missed | Passed |
| The primary background token for buttons references a semantic action or interactive token instead of referencing a raw color primitive. | Passed | Passed |
The instructions your model reads when the skill loads.
Design tokens are named, structured key–value pairs that store every visual decision in a design system — color, spacing, type, radius, motion — as data instead of hardcoded literals. One token (color.bg.default) is authored once and consumed everywhere: Figma, CSS, iOS, Android, Tailwind. Change the value, every surface updates. Tokens turn "the brand blue" from a number scattered across 400 files into one row that design and engineering both point at.
#2563EB typed by hand in a component.Tokens flow in one direction. Components reference semantic. Semantic references primitive. Primitive references nothing. Never let a component reach past semantic into a raw primitive.
| Tier | AKA | Holds | Example | Themeable? |
|---|---|---|---|---|
| 1 — Primitive | global, base, core, option | Raw, context-free values | color.blue.500 = #2563EB, dimension.4 = 16px | No — fixed palette |
| 2 — Semantic | alias, decision, system | Intent, references a primitive | color.bg.default → {color.gray.50} | Yes — modes flip here |
| 3 — Component | scoped | Component-specific, references semantic | button.primary.bg → {color.action.default} | Inherits from semantic |
┌─────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ PRIMITIVE │ ◄── │ SEMANTIC │ ◄── │ COMPONENT │
│ blue.500 │ │ color.action.def │ │ button.primary.bg │
│ #2563EB │ │ {color.blue.500} │ │ {color.action.def}│
└─────────────┘ └──────────────────┘ └──────────────────┘
raw value intent / role local override
When to add each tier:
color.bg.default. Themes are impossible without this tier — it is not optional polish.button.*). Don't create a component token for every CSS property — most components should consume semantic tokens directly. Apply the rule of 3: don't mint a component token until the override repeats.The aliasing rule, stated plainly: a component should never know that the brand color is blue. It knows color.action.default. The semantic layer is the only layer that maps intent→primitive, so it is the only layer a theme has to override.
test cases passed, vs 21 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.