Getting consistent design tokens from Claude

Why tokens drift even when each generation looks reasonable

Design tokens — the named values for colour, spacing, type scale that a system is built on — are exactly the kind of thing that's easy to regenerate slightly differently each time if they're not anchored to a single authoritative source. Ask for a spacing scale once and you'll get something reasonable; ask again in a later session, without referencing the first answer, and you'll likely get something equally reasonable but subtly different — not wrong, just not the same values, because nothing tied the second answer to the first.

Establish the source of truth once, and always reference it

The fix isn't better prompting on each individual request — it's treating the token set as a single, established source of truth that every subsequent request references rather than regenerates. Once a token set exists, feed it back in explicitly on every request that touches styling, rather than trusting that Claude will independently arrive at the same values it produced in an earlier, separate conversation. Tokens that exist only in an old conversation's output, uncaptured anywhere durable, are effectively token values that will drift the next time they're needed.

Naming conventions matter as much as the values themselves

Two token sets with functionally identical values but different naming conventions are not interchangeable in practice — code written against one naming scheme doesn't work against the other without a rename pass, and inconsistent naming across a codebase's token references is a common, avoidable source of confusion. Decide on a naming convention explicitly before generating any tokens, and treat that convention as part of the source of truth alongside the values themselves, not as an afterthought each request can reinterpret independently.

Where semantic tokens help more than raw values

A raw value (a specific colour) and a semantic token (what that colour is for — a warning colour, a primary action colour) serve different purposes, and systems that skip the semantic layer tend to accumulate direct references to raw values scattered everywhere, which makes a later rebrand or theme change far more invasive than it needs to be. Establishing semantic tokens early, even for a small system, pays off specifically at the moment something needs to change — a rebrand touches the semantic token definitions once rather than every place a raw value was used directly.

Auditing for drift periodically

Even with a well-established source of truth, drift can creep in through components generated in isolated sessions without the full token reference available, or through manual overrides added under time pressure. Periodically auditing generated code against the actual token definitions — checking for hardcoded values that should have referenced a token instead — catches this drift before it accumulates into a system that's inconsistent in ways nobody planned or noticed happening gradually.

Storing tokens somewhere both you and future requests can reference

The most durable fix is giving the token set an actual home — a dedicated file or document that's the single canonical reference — rather than letting it live only as the output of a past conversation that becomes progressively harder to find and re-supply the further removed a new request is from when it was originally generated. Once that home exists, every future request that touches styling can point at it directly, which removes the guesswork entirely rather than relying on a careful prompt to reconstruct values that were already decided once.

Treating a token change as a migration, not a tweak

Once tokens are in real use across a codebase, changing one isn't a small edit — it's a migration that touches every place the old value was referenced, and skipping that step leaves some components on the old value and others on the new one, silently reintroducing the exact inconsistency the token system was built to prevent. Treat any token value change as a deliberate migration with its own review, not a quick edit to the token definition alone.

See using Claude for component design systems for how token consistency fits into the broader discipline of keeping a whole system coherent across many separately-generated components.