devotionn Design Tokens
Use when
Creating, extending, normalizing, or migrating a product's design tokens.
Procedure
- Inventory existing variables, theme files, utility configuration, component constants, and hardcoded values.
- Preserve existing public token names when changing them would create unnecessary migration risk.
- Prefer a three-tier model when the project can support it: primitive values → semantic intent → component tokens.
- Use DTCG-compatible structure for portable token artifacts unless the existing system has a stronger native contract.
- Define light/dark or other theme mappings at the semantic layer rather than duplicating component logic.
- Include color, typography, spacing, sizing, radius, border, elevation/shadow, motion, and breakpoint concepts only where the product actually needs them.
- Validate aliases/references and detect unresolved tokens.
- Render representative components before asserting that token changes are visually safe.
Failure conditions
Do not create token aliases that resolve cyclically or to missing values. Do not claim a theme migration is complete while material hardcoded design values remain unexplained.