Consuming a design system

You are wiring a product to a design system someone else owns: installing its token release, binding tokens into your CSS/framework layer, theming, or upgrading across a version bump. This skill orients you across that lifecycle and points at the skill that carries each station's actual rules — it does not re-teach them here.

When to use

• Installing a design system's token package into a product for the first time.
• Wiring tokens to CSS variables, Tailwind config, or framework-native theme primitives.
• Adding or changing a theme (light/dark, brand variant, density) in a product that consumes a system.
• Upgrading across a token release — reading a token-diff, mapping deprecations, choosing a bump-aware upgrade path.
• Deciding whether a product-specific need should alias existing tokens, get proposed upstream, or justify a fork.

When NOT to use

• Building, extending, or authoring a design system's own token catalog — load designing-a-design-system instead.
• Reviewing a PR or rendered UI for compliance with a system's rules — load reviewing-design-work instead.
• This skill is for the consumer side of the relationship only; it assumes the system already exists.

1. Token discipline

Product source references tokens through CSS variables or framework bindings — never raw hex, rgb, or px values. Picking the right token depends on reading its name correctly (class, kind, role) rather than guessing from context.

REQUIRED BACKGROUND: token-naming-conventions

For user-facing string consistency alongside token consistency, see brand-voice-review.

2. Composition rules

Prefer semantic tokens over primitives in product code; theme and density are runtime axes, not name segments — see token-naming-conventions.

3. Install patterns

A system publishes its source of truth as a DTCG snapshot; everything a product consumes — CSS variables, Tailwind config, iOS/Android/Flutter primitives — is transformed from that snapshot, not authored by hand.

REQUIRED BACKGROUND: dtcg-format

Pin the version you consume. Treat the transform pipeline (snapshot → transformer → CSS variables / framework primitives) as the install contract: if a product hand-edits the generated output, the next re-generation silently reverts it.

4. Migration & upgrade

Before bumping a consumed system's version, read its token-diff report rather than diffing files by eye — the diff is what tells you what actually changed at the resolved-value level, not just the source paths. Map every deprecated token to its replacement during the deprecation window; don't let a removal land as a silent breakage on the next major.

REQUIRED BACKGROUND: semver-design-tokens

The bump severity tells you whether product code must change — see semver-design-tokens.

5. Extending vs. consuming

• Alias, don't fork — and only as a fenced interim. A product-local token for something the system doesn't provide yet is authored on top, aliasing system tokens, never duplicating or forking the catalog — and it is interim, not standing: opened against an issue on the system's tracker, and deleted the moment the upstream token lands. An alias with no linked issue and no removal condition is drift wearing the alias pattern.
• Fork only when you own the whole lifecycle. A fork means you now maintain contrast floors, SemVer discipline, and migrations yourself; that's a heavier commitment than most product-specific needs justify.
• Upstream recurring extensions. If the same product-local alias keeps getting reinvented across teams, that's the signal to propose it to the system's maintainers — not to leave it as permanent private drift.

One system's worked instantiation of a consumer-facing contract (incubating, not yet loadable): udts-token-model, udts-linter-rules.

Cross-references

L0 primitives:

• token-naming-conventions — name-shape rules for picking/validating a token by its name.
• dtcg-format — the DTCG interchange format a system's snapshot is published in.
• semver-design-tokens — SemVer bump severity and deprecation-cycle discipline for token releases.
• brand-voice-review — microcopy voice consistency for user-facing strings.

L2 stances (incubating — parity markers, not yet loadable guidance):

• udts-token-model — one system's worked token taxonomy as a consumer-facing contract.
• udts-linter-rules — one system's worked machine-enforceable consumer rules.

Sibling L1 dispatchers:

• designing-a-design-system — building or extending a system (not consuming one).
• reviewing-design-work — reviewing design output against a system's rules.