How to use the Design Token Naming Generator.
Design token names should describe a stable role rather than a temporary appearance. Separate primitive values from semantic uses and check consistency with the team's existing naming convention.
Make the workflow fit your task.
Separate primitive values from semantic roles and follow the existing naming hierarchy. Choose names that remain meaningful across themes and components, then document mappings and intended usage. Check collisions and aliases before renaming established tokens.
- What you provide
- Existing styles and naming conventions.
- What you get
- Consistent token names and semantic groupings.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Interface uses blue for primary actions and gray for secondary text; dark theme planned. No exact values or existing naming convention supplied.
Completed example
Semantic roles: color.action.primary → theme-specific primary-action primitive color.text.secondary → theme-specific secondary-text primitive Theme values: unresolved until actual colors and contrast requirements are supplied. These names describe use rather than the current color; review them against existing team conventions before adoption.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Should a semantic token be named after its current color?
Prefer its role, such as action or secondary text, when the value may change across themes.
Why does a token rename break several unrelated components?
The token may be widely referenced or serve multiple roles. Inventory consumers and plan the migration before replacing it.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑