From check to token 7 min live
A written standard says what good looks like. A token makes good the path of least resistance. That is the whole difference, and it is why systems work where documents do not. Take the five checks from b5 one at a time. The type scale becomes a set of size tokens generated from one ratio, so there is no size available that is not on the scale. The spacing unit becomes a spacing scale, so there is no gap available that is off the grid. Contrast becomes something subtler and more powerful: not a palette of approved colours but a set of pre-checked pairs. The accent becomes exactly one accent family plus semantic status colours. And hierarchy becomes component variants rather than free-form styling.
LiveWhy colour must ship as pairs4 min▶
Most design systems publish a palette: twelve swatches with names and hex values. Then a designer picks a nice grey for body text, drops it on a nice pale plum surface, and ships something that measures 3.1:1. Nobody broke a rule. The system just handed them enough rope.
The fix is to stop treating colour as a list of colours. Publish combinations instead:
- A pair token names both sides.
text.default / surface.default,text.onAccent / surface.accent,text.muted / surface.subtle. Each pair is measured once, at authoring time, and only exists if it passes 4.5:1. - There is no loose ink. If a token gives you text colour without a surface, it is an invitation to guess. Make the surface part of the token's identity.
- Muted has a floor. The most common real-world failure is the "secondary text" grey that passes on white and fails on every tinted surface. Publish
text.mutedonly for surfaces where it was checked. - Non-text gets its own pairs. WCAG SC 1.4.11 wants 3:1 on control boundaries, so borders and focus rings need pre-checked pairs too. This is why a pale outline is a defect, not a style.
The payoff is that an AI tool inherits the discipline for free. Hand a generator a palette and it will compose a failing pair within three screens. Hand it pair tokens and the failure mode is no longer available.
Self-studyGenerating the scale instead of picking it3 min read▶
The lab uses a 1.25 ratio from a 16px body: 12 / 14 / 16 / 20 / 25 / 31 / 39. Nothing in any standard requires 1.25. What matters is that one ratio produces the whole set, so the set stays small and related, and so a new size cannot be invented in a hurry.
- Write the ratio down as the token, not the sizes. If the ratio is the source, adding a size means changing a number in one place and regenerating - which is a review, not a whim.
- Round once, deliberately. 1.25 from 16 gives 20, 25, 31.25, 39.06. Pick your rounding rule and keep it, because half-pixel type is a rendering lottery.
- Cap the set. Four to six sizes in a product UI is plenty. Every extra size is a hierarchy decision you are deferring to whoever is on the file next.
- Spacing works the same way. One unit, powers and multiples of it, and a hard rule that nothing off the scale ships. Eight is a convention with good divisibility, not a spec.
Both of these are conventions, and you should say so in a review. What is not a convention is the contrast floor, which is where the pairs come in.
What "design tokens" formally means 6 min live
There is a shared file format for tokens, and it is worth knowing its exact status because people cite it wrongly in both directions. The W3C Design Tokens Community Group format has a stable version, 2025.10, published as a Final Community Group Report on 2025-10-28. "Final Community Group Report" is a real, citable milestone, and it is explicitly not a W3C Standard. So: yes, build on it. No, do not tell a stakeholder the W3C standardised your tokens.
LiveCite the right URL, and know why4 min▶
Two URLs, two very different documents:
- Cite this one:
https://www.designtokens.org/TR/2025.10/format/- the stable 2025.10 Final Community Group Report. Versioned, dated, safe to implement against. - Do not cite this one: the older
tr.designtokens.org/format/address now redirects to an unstable living draft that says outright not to attempt to implement that version. If your team's wiki still links there, your team is reading an editors' draft and thinking it is the spec.
The practical consequence: pin the version in your own docs. "Cadence tokens follow DTCG 2025.10" is a sentence an engineer can act on. "Cadence tokens follow the W3C token spec" is a sentence that will be true of a different document in six months.
Tokens Studio is the usual bridge in a Figma-centred team. It supports both the DTCG format, where token properties are $-prefixed, and its own older legacy format, and it exports to Figma Styles and Variables. Pick one format for your repo and be boring about it - mixed formats are where token pipelines quietly rot.
Self-studyWhat belongs in a token and what does not3 min read▶
A token is a named value with a type. That is deliberately small. The temptation is to encode judgement in it, and judgement does not survive being a variable.
- Good token:
space.3= 24px.font.size.4= 25px.pair.text.onSurface= ink #2A1A28 on surface #FFFFFF, measured 15.2:1. - Bad token:
colour.friendly,space.comfortable,type.hero. These describe a feeling, so two people will read them two ways, and an AI tool will read them a third. - Semantic beats literal at the point of use. Keep a primitive layer (raw values) and a semantic layer that references it. Components consume the semantic layer only, so a rebrand is a change in one place.
- Status colours are semantic by definition.
status.success,status.warning,status.danger. They are the only sanctioned hues outside the accent family, and each needs its own pre-checked pairs.
How an AI tool actually reaches your system 7 min live
"Just point the AI at our design system" is a sentence with a lot of engineering hiding behind it. There are five real routes, and every one has a gate: a seat tier, a deadline, a scope limit or a feature carve-out. The most important single fact for anyone planning token automation is that the Figma variables REST API is Enterprise-only - the docs are blunt about it, you must have a Full seat in an Enterprise org. Below Enterprise, your only token route is the Figma MCP server, and it reads the current selection, not the file.
| Route | What it gives an AI tool | The gate |
|---|---|---|
| Figma variables REST API | Programmatic read of variables and modes across a file - the route you would design a pipeline around | Enterprise only. "You must have a Full seat in an Enterprise org". No workaround below that tier. |
| Figma MCP server | get_variable_defs returns the variables and styles in your selection. Also get_design_context (which replaced get_code), get_code_connect_map, get_code_connect_suggestions, and remote-only search_design_system |
Remote endpoint https://mcp.figma.com/mcp, desktop http://127.0.0.1:3845/mcp. Scoped to what is selected, so coverage depends on a human selecting the right frames |
| Figma Code Connect | Maps your real coded components to Figma nodes, so generated output references components that exist | Dev or Full seat on Organization or Enterprise. Framework-specific parsers lose updates and support from 2026-08-17; after that, template files are the only maintained path |
| v0 Design Systems 2.0 | Stores your system as a "skill" - an adapter naming where the source lives and which components, props and tokens are safe to use | Fed from GitHub repos, npm packages, Figma frames, Storybook or docs links, or screenshots, and writes a v0.json. Quality of the adapter is on you |
| shadcn registry | Components and tokens an agent can install by URL, so "use our button" means fetching our button | registry.json → shadcn build → serve at /r/[NAME].json → shadcn add <url>, with shadcn mcp init --client ... for multi-registry access. "Open in v0" does not support cssVars, css, envVars, namespaced registries or advanced auth |
| Vendor MCP servers | Official servers exist for Storybook, MUI, Chakra (get_theme), Ant Design (antd_token) and Adobe React Spectrum |
Only useful if you actually build on that library. There is no official Google or Material 3 MCP server - anything you find is community-maintained |
LiveWhat to do if you are not on Enterprise4 min▶
Most teams reading this are not on Enterprise, so the honest plan is different from the demo you saw at a conference:
- Make the repo the source of truth, not the Figma file. If your tokens live in a versioned file that both humans and agents can read, the Enterprise API stops mattering. Tokens Studio can push in that direction.
- Use MCP for the last mile, not the pipeline. Selection-scoped
get_variable_defsis genuinely useful when you are handing one frame to a tool. It is not a sync mechanism. - Plan around 2026-08-17 now. If you have Code Connect set up with framework-specific parsers, that path stops receiving updates and support from that date. Template files are the maintained route after it. Migrating on a calm week beats migrating on a broken one.
- Prefer routes that name the allowed set. The reason v0 skills and shadcn registries work well is not magic - it is that both make a tool cite specific components instead of inventing plausible ones.
Self-studyAsk for token names, not for vibes2 min read▶
The single highest-leverage change to how you prompt a UI generator is to stop describing your system and start listing it.
"Build the Cadence share-summary panel. Match our design system - it's clean and modern, plum accent, plenty of whitespace. Use our components where you can."
"Build the Cadence share-summary panel using only these tokens: font.size.1-5 (12/14/16/20/25, ratio 1.25 from 16); space.1-6 (8/16/24/32/40/48); pair.text.onSurface (#2A1A28 on #FFFFFF), pair.text.muted.onSurface (#7A6A78 on #FFFFFF), pair.text.onAccent (#FFFFFF on #6B2D5C); accent family is plum only; status.success / status.warning / status.danger for state.
Allowed components: Button (primary | secondary | quiet), Card, Badge, Avatar, Toggle, Toast.
Forbidden: raw hex values, gradients, any font size or spacing value not listed above, a second accent hue, more than one primary Button per view, icon-only buttons under 24x24 CSS px.
If a required value is missing from the token list, stop and tell me rather than inventing one."
The last line is the one people skip and the one that saves you the most time. A generator that stops and asks is a generator you can trust with a second screen. A generator that invents #7B2E63 because it was close has just introduced a token you will find eight screens later.
Tokenise Cadence, then verify it ★ 14 min · everyone runs it
We are going to write Cadence's token set out loud, then prove it. The lab below starts with hierarchy, type scale and spacing already on - 66 out of 100 - because those are the three checks you tokenised in Part 1. What is left is the interesting part: contrast and the accent. Bring each one on and notice that you are not making a styling decision. You are making a token decision, and the score is what a token decision looks like from outside.
Write the scale as a ratio. 1.25 from a 16px body gives 12 / 14 / 16 / 20 / 25. Five sizes, one source. Anything the draft used that is not on this list is now a bug with a name.
Write the spacing scale. One unit of 8px, so space.1 through space.6 = 8 / 16 / 24 / 32 / 40 / 48. Say the rule out loud: nothing off the scale ships.
Turn on Contrast and read 86. Do not think of it as darkening text. You have just replaced loose colours with pre-checked ink-on-surface pairs, and the survivors in the failure rows are exactly the places where a pair was never defined.
Turn on One accent and read 100. One plum family plus named status colours. The fourth hue that was floating around had no token, no name and no owner - which is why it kept coming back.
Now press Add colour and watch 100 become 81. Nineteen points. That is what "let's just brighten it up" costs when the brightening has no token behind it.
The enforcement ladder 5 min live
Teams tend to jump from "we have a Figma library" to "we need lint in CI" and skip the two layers in between, which are the cheap ones. Each layer catches more than the last and each one still leaks. Knowing what each layer lets through tells you which layer to build next, and stops you buying automation for a problem a written rule would have solved.
Self-studyLayer 4 without a platform team3 min read▶
You do not need CI to get most of layer 4. You need something that runs the same check every time, on the same evidence:
- A token diff in the pull request. If tokens live in a versioned file, any new value shows up as a line in a review. That is a gate.
- A contrast check on the pair list, not on screens. Because pairs are defined once, checking them is a small, fixed job rather than an audit of every view.
- A standing agenda item. Five checks, five minutes, same order, every design review. Boring and effective, and it is the layer most teams skip while shopping for tooling.
b9 takes this into handoff: the same tokens, the same allowed component list, expressed in a way an engineer and an agent can both consume.
Try it yourself - this week ◐ 30-40 min total
- Write your product's real token set on one page: the type ratio and the sizes it generates, the spacing unit and its scale, your accent family, your status colours, and every ink-on-surface pair with its measured ratio. Where a pair fails, do not fix the colour yet - just mark it.
- Audit for loose ink. Find every place your system publishes a text colour without naming the surfaces it was checked against. That list is your next sprint of token work, and it is usually shorter than people expect.
- Check which token route you actually have. Are you on Enterprise, so the variables REST API is available? If not, write down the honest plan: repo as source of truth, MCP for the last mile. If you use Code Connect with framework-specific parsers, put 2026-08-17 in a calendar with a migration owner.
- Take the "named and bounded" prompt from Part 3, swap in your own tokens, allowed components and forbidden patterns, and run it against a screen you already shipped. Compare what comes back to the real thing and note every place the tool went outside the list.
Official sources covered
This session teaches the token format at its real status and the access routes at their real gates, verified from official documentation. Anything about seats, endpoints or deadlines in this space moves, so re-check the vendor page before you build a pipeline on it. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · What is the formal status of the W3C Design Tokens Community Group format, version 2025.10?
Both extremes are wrong. 2025.10 is a real, citable, stable milestone you can build against - cite www.designtokens.org/TR/2025.10/format/ - but it is a Community Group Report, not a W3C Standard. Option C describes the living draft you land on from the older tr.designtokens.org URL, which is exactly why that link should not be in your team wiki.
2 · Your team is on Figma Professional and wants an agent to read every variable in a file. What is the honest answer?
This is the single biggest constraint on token automation, and it surprises people late in a project. The REST API is Enterprise-only. MCP's get_variable_defs reads what is selected, not the file, so coverage depends on a human selecting the right frames. Code Connect is also gated - Dev or Full seat on Organization or Enterprise - and its framework-specific parsers lose updates and support from 2026-08-17.
3 · Why publish colour as pre-checked ink-on-surface pairs rather than as a palette of swatches?
A palette hands people enough rope: a nice grey on a nice tinted surface measures 3.1:1 and nobody broke a rule. Pairs move the measurement to authoring time, so the token either exists and passes or does not exist. It also means an AI tool inherits the discipline without being told about it. WCAG sets the ratio, not the documentation format.