DTCG Design Tokens: What 15 Design Systems Actually Ship

Three out of 15. That's how many public design systems ship DTCG design tokens in the npm package their teams actually install, when we opened the packages on 19 October 2026. The other twelve ship tokens as older JSON, as CSS variables, or as JavaScript objects.

The Design Tokens Community Group published the first stable version of its specification, 2025.10, on 28 October 2025. Most writing about it explains the spec or lists adopters second-hand. We wanted to know what teams publish, so we downloaded the packages and counted.

What is a DTCG design token?

A DTCG token is a JSON object with a $value, usually a $type, and optionally a $description. Groups nest tokens, and a value in curly braces, like {color.blue.500}, is an alias to another token. The dollar signs are the point: they separate the spec's own keys from your names, so any tool can tell a token from a group without knowing your naming scheme.

Before the spec settled, most teams used a value key without the dollar sign, the shape popularised by Style Dictionary. It works, but every tool has to guess which objects are tokens and what type they hold.

How we checked

For each system we took the package that carries its tokens, downloaded the latest version from the npm registry on 19 October 2026, and read every JSON, CSS, Sass and JavaScript file in it. A package counted as DTCG if its token files use $value. It counted as older JSON if tokens use value. Otherwise we recorded what it ships instead.

We picked mid-size and well-documented public systems whose tokens are on npm. It's a sample, not a census, and a team can keep DTCG files in its repository without publishing them. What we measured is what a consumer, or a consumer's coding agent, gets after npm install.

The results, system by system

Source: the npm packages linked in the table, downloaded 19 October 2026. "Descriptions" means a description field on the token itself, not documentation elsewhere.

Three things the data says

DTCG is real but early. GitLab's Pajamas is the strongest example in the sample: 7,285 tokens with $value and $type, about half with a $description, and 630 colours already written as objects with a colorSpace, the colour format in the stable spec. GitLab puts light and dark values inside a single $value, its own convention; the stable spec describes modes in a separate resolver file. Cedar builds DTCG-keyed JSON for each platform. WordPress publishes 30 DTCG tokens, but only as a Figma export.

The older JSON is one rename away. Five systems, including Spectrum and Paste, already ship structured JSON with types and, often, descriptions. Moving to DTCG is mostly renaming keys and checking aliases. The structure is there.

Seven of 15 ship no token JSON at all. In the Vibe package, as in Canvas, Skin and Radix Colors, tokens are CSS variables; Garden, EUI and Orbit ship JavaScript objects. Those work well for the apps that import them. They're harder for anything that has to read the tokens rather than run them.

Why the file format matters more now

A year ago a token file had two readers: your build pipeline and your design tool. Now it has a third. Coding agents read your packages to decide which colour, space or radius to use, and they do it with whatever the package gives them.

Vibe's --negative-color-selected: #f4c3cb is readable. A person sees the name and knows roughly what it's for. An agent sees a string and a hex value, and has to guess from the name when to use it and what it pairs with. GitLab's avatar.border.color.default, with $type: color, aliases for light and dark mode and a $description that says "Used to define the edge of an avatar", can be resolved: the agent can look up what it is, what it points to and when to use it, without guessing.

That's the gap between documentation written for people and context an agent can act on, and token files are where it's cheapest to close. If you're thinking about what else agents need from your system, what makes a design system AI-ready covers the rest of the list.

What to do if your tokens aren't DTCG yet

• Find out what you ship: run npm pack on your tokens package and look inside. What's in the tarball is what consumers and their agents get, whatever lives in your repository.
• If you have value JSON: rename to $value, $type and $description, then check your aliases still resolve. Style Dictionary's DTCG page has a converter that does the renaming, though it notes that 2025.10 isn't fully supported yet.
• If you only ship CSS or JS: add a JSON output next to it from the same source. You keep the CSS for apps and gain a file tools can parse.
• Write descriptions where intent isn't obvious: semantic tokens like negative-color-selected need a sentence on when to use them. Base palette values rarely do.

If tokens are new territory for your team, start with how to manage your design tokens and how Figma variables differ from design tokens.

Where Supernova fits

Supernova keeps tokens, components and documentation together and serves them to agents over MCP "as structured data, not a page to interpret", as our MCP page puts it. Whatever format your package ships, the agent gets the same answer to "which token do I use here" from one place. If you want to see how that looks for your system, the MCP page has the setup.

The one thing to do on Monday

Open your tokens package and count the files a tool could parse without your build. If the answer is zero, adding one JSON output is a small change that every agent working in your codebase will use the same day.