TLDR: Claude generates and audits design token systems — two-tier primitives/semantics, dark mode mapping, naming drift audits, format conversions — much faster than doing it by hand. Ask for explanations on the first generation so you understand the model's logic before it generates 400 more tokens with the wrong mental model.
Design tokens are the unglamorous backbone of every design system — the named values that connect Figma to CSS to your component library. Getting them right is tedious. Keeping them consistent across a growing codebase is hard. Scaling them across light/dark mode, multiple themes, and brand variations is the kind of work that feels like it should be automated.
It can be. This is a practical guide to using Claude as a frontend developer, with design tokens as the running example — from generating your first token set to auditing naming drift in a mature system.
What Claude actually does here
Quick clarification before we get into prompts: Claude doesn't look things up or connect to your Figma. It reasons about whatever you paste into the conversation and generates output from that context. For design token work specifically, the four modes I actually use it in:
- Code generator — write a token set from a description or existing brand values
- Reviewer — spot naming inconsistencies, missing states, drift across a mature system
- Transformer — convert between formats (JSON → CSS custom properties → Tailwind config)
- Thinking partner — work through naming architecture before committing to 400 tokens
What it's not: it doesn't know your design history, it can't see your Figma file unless you paste the values, and the 10% you'll want to adjust after generation is the most important 10%. That part is still yours.
Picking the right model
| Model | Best for | Cost (INR/MTok input) |
|---|---|---|
| Claude Haiku 4.5 | Simple transformations, format conversions, repetitive token generation | ₹68 |
| Claude Sonnet 4.6 | Designing a full token system, naming architecture, dark mode mapping | ₹255 |
| Claude Opus 4.7 | Multi-brand token strategy, accessibility audits, complex system design | ₹1,275 |
For most design token work, Sonnet is the sweet spot. Smart enough to understand semantic naming conventions, fast enough for rapid iteration.
The prompt formula
The quality of what Claude gives you depends entirely on what you give it:
[Context] + [What you have] + [What you want] + [Constraints]
Weak:
give me design tokens for a button
Strong:
I'm building a design system for a fintech SaaS app using CSS custom
properties. Brand primary is #1A6BFF, font is Inter.
Generate a semantic design token set for a primary Button component.
Include:
- Color tokens (default, hover, active, disabled states)
- Spacing tokens (padding, gap)
- Typography tokens (font-size, font-weight, line-height)
- Border tokens (radius, width)
- Transition tokens
Use a two-tier system: primitive tokens (raw values) and semantic tokens
(referencing primitives). CSS custom property format. No Tailwind.
The second prompt produces a complete, structured token set on the first try. The first produces generic noise that you'd have to heavily revise.
Generating a two-tier token system
A well-designed token system has two layers:
Primitive tokens → raw values with no semantic meaning
--color-blue-500: #1A6BFF;
Semantic tokens → named by purpose, reference primitives
--color-action-primary: var(--color-blue-500);
Ask Claude to generate both layers in one shot:
Generate a two-tier CSS custom property token system for a B2B SaaS product.
Primitives needed:
- Color scale: blue (50–900), grey (50–900), red (50–700), green (50–700)
- Spacing scale: 4px base unit, steps: 2, 4, 8, 12, 16, 24, 32, 48, 64, 96
- Typography: size scale (12–48px), weight (400, 500, 600, 700), line-height (1.2, 1.4, 1.6)
- Border radius: 2, 4, 8, 12, 16, 9999 (pill)
- Shadow: 3 elevation levels
Semantic tokens needed for:
- Text: primary, secondary, disabled, inverse, error, success
- Background: page, surface, overlay, hover, active
- Border: default, strong, focus, error
- Interactive: action primary/secondary/destructive (+ hover/active/disabled states)
Output: valid CSS inside a :root {} block. Brief comment above each group.
Claude will generate 200–400 lines of clean, production-ready CSS in one pass. I've done this for two client projects and the output is a solid starting point with maybe 10-15% I'd want to adjust.
Converting between formats
Design tokens live in multiple formats across your toolchain — Figma tokens plugin exports JSON, your component library wants CSS custom properties, your utility framework wants a Tailwind config. Claude handles all three conversions.
JSON → CSS Custom Properties
Convert this design token JSON to CSS custom properties.
Keep the naming structure. Flatten nested objects using -- as separator.
Output only the CSS, no explanation.
[paste your tokens.json here]
CSS → Tailwind Config
Convert these CSS custom property tokens to a Tailwind CSS v4 theme
configuration. Map color tokens to the colors key, spacing to spacing,
and typography to fontSize. Use CSS variable references, not hardcoded values.
[paste your :root CSS here]
Style Dictionary Format
Convert this flat CSS token file to Style Dictionary JSON format.
Group tokens by category (color, spacing, typography, shadow).
Each token should have value, type, and description fields.
[paste your tokens.css here]
What used to be a custom script per-conversion is now a prompt.
Dark mode token mapping
Dark mode is where token systems break down. Most teams end up with either duplicate values or hacky overrides per component. The right pattern is a semantic layer that remaps to a dark palette.
I have these light mode semantic tokens:
--color-bg-page: var(--color-grey-50);
--color-bg-surface: var(--color-white);
--color-text-primary: var(--color-grey-900);
--color-text-secondary: var(--color-grey-600);
--color-border-default: var(--color-grey-200);
--color-action-primary: var(--color-blue-500);
--color-action-primary-hover: var(--color-blue-600);
My dark palette primitives:
--color-grey-950: #0A0A0F
--color-grey-900: #111118
--color-grey-800: #1C1C27
--color-grey-700: #2A2A3A
--color-grey-400: #8888AA
--color-grey-200: #CCCCDD
--color-blue-400: #5599FF
--color-blue-300: #80BBFF
Generate dark mode overrides using a [data-theme="dark"] selector.
Same semantic token names — only the values change.
Explain the reasoning for each mapping choice.
Asking for the reasoning on the first generation is deliberate. You want to understand why --color-bg-surface maps to grey-800 and not grey-900, so you can correct Claude's understanding before generating 400 more tokens with the wrong mental model.
Naming audit
Token systems drift as they grow. Three months in, you have --button-bg, --card-background, and --modal-bg all referencing the same primitive. The inconsistency is invisible until a new developer joins and is confused about which one to use for a new component.
Paste your full token file and ask Claude to audit it:
Audit these design tokens for naming inconsistencies:
1. Same concept named differently (e.g. "bg" vs "background" vs "fill")
2. Missing states (hover/active/disabled) that exist for some components but not others
3. Tokens using raw values that should be semantic
4. Names tied to specific components instead of purpose
For each issue: show the problem tokens, explain the issue, suggest the fix.
[paste your token file]
This is the kind of review that takes a senior design engineer half a day. Claude does it in under a minute. I ran this on a token file that had accumulated drift over 18 months and it found 23 inconsistencies I'd completely missed.
Three rules for better output
Paste, don't describe. If you have existing tokens, paste them. Claude working with real data produces dramatically better output than Claude guessing at your structure.
Ask for one thing at a time. "Generate primitives" → review → "now generate semantics from these primitives" → review → "now map dark mode." Chaining produces better results than one giant prompt.
Request explanations on the first generation. Not for every subsequent call — just the first one, so Claude's mental model of your system matches yours before it generates 400 more tokens.
What Claude can't do here
It doesn't know your design history. If a token was named a certain way for a legacy reason, Claude will rename it. Always review output against your existing conventions.
It can't see your Figma. Paste token values — don't expect it to read a Figma link or interpret a screenshot accurately.
Generated systems need human curation. Claude gives you a strong starting point. The 10% you adjust after generation is the most important 10% — it's where your judgment about your product lives. Don't skip that part.