Use the tokens in the workflow you already have.

Hand the file to an LLM

Attach design.tokens.json with your project and use this prompt:

Use the attached design.tokens.json as the source of truth for visual design decisions. Preserve every token name, type, value, unit, and alias. Map the tokens into the conventions of this project without changing the source file. Do not invent missing tokens or infer brand claims. Before editing code, explain the mapping you will use. After implementation, report any token that could not be represented exactly.

Use it directly

Each top-level key is a token group. Every token declares a $type and a $value. A value can be a literal, an alias such as {color.accent}, a number paired with a unit such as { "value": 16, "unit": "px" }, or a composite object such as a shadow.

1. Keep design.tokens.json unchanged as the source of truth.
2. Transform or import it at your project boundary.
3. Read the full document before resolving aliases so referenced tokens are available.
4. Preserve units and every field in composite values when mapping to the target platform.
5. Validate generated output against the source token names, types, and values.

What the file guarantees

Stable names, explicit types, deterministic bytes, a terminal line feed, and standards-based values. How those values become CSS, native code, design tooling, documentation, or generated interfaces remains your choice.