Tonex exports shadcn and json natively. For every other tool, use Tonex as the semantic source: generate a read target, map roles by intent, then prove the final pairings with check.
Choose a read target
| Target | Use when |
|---|---|
--to colors | An agent or script needs the raw role set for custom mapping. |
--to yaml | The target tool can consume a DESIGN.md colors: block, or you want a portable semantic contract. |
npx @tonex-dev/cli generate --seed "#6A9CFF" --to colors
npx @tonex-dev/cli generate --seed "#6A9CFF" --to yamlMap by intent
Role names are a starting point, not a binding rule. Map each Tonex role to the target tool slot that preserves the same visual job.
For example, another tool might call its main action color brand, accent, or button. Bind Tonex primary there if that slot is the product's primary action. Binding secondary to another tool's primary-looking slot can also be correct if it preserves the intended hierarchy.
Verify the mapped pairs
After mapping, check the pairs the target UI will actually render:
npx @tonex-dev/cli check --seed "#6A9CFF" --pairs '[["--color-on-surface","--color-surface"]]'Token-name pairs use the CSS variable form with a --color- prefix:
| Tonex role | Pair-check token |
|---|---|
primary | --color-primary |
on-surface | --color-on-surface |
surface | --color-surface |
The contrast guarantee follows the pairing you check, not the name you keep in the target tool.
Discipline
Do not invent colors during the mapping step. If a mapped tool needs a different hierarchy, remap Tonex roles first; if a checked pair fails, use a Tonex remedy such as --contrast or choose a different pairing. See How Tonex thinks.