design-token-generationlisted

# Typographic design token generation Tokens are how a type scale survives contact with a codebase. A scale that isn't enforced is a suggestion. ## 1. When to invoke - Turning a type scale into tokens, CSS variables, or theme config. - Naming typographic tokens. - Exporting type across platforms (web, iOS, Android). - A token set has accumulated arbitrary values, or design and code disagree. **Do not** invoke to design the scale (`hierarchy-and-scale`) or choose the face (`typeface-selection`). Tokenize decisions already made. ## 2. Required context - The **finalised scale** and its rationale. - **Target platforms** and their unit conventions. - Whether tokens must support **theming** (density modes, brand variants). - Whether the pipeline is **generated** (Style Dictionary, Figma variables) or hand-maintained. - Whether **fluid/responsive** values are in scope. ## 3. Invariant principles - **Three tiers: primitive → semantic → component.** - *Primitive* — raw values, no meaning: `font-size-300: 1.125rem`. - *Semantic* — role-based, referencing primitives: `text-body-size`. - *Component* — component-scoped, referencing semantics: `button-label-size`. Components consume semantics. Semantics consume primitives. **Never let a component reference a primitive directly** — that's how a scale erodes. - **Name by role, never by appearance.** `text-body`, not `text-16` or `text-grey`. Appearance names become lies the first time the value changes. - **Never name b