Skip to content
Intermediate30 min· April 15, 2026

Audit your codebase's design tokens against your Figma library in 30 minutes

Cursor + your component library + your tokens.json — one prompt surfaces every drift between design and code.

Curator’s note

“If you've ever asked "is our design system actually being used?" and nobody had an answer — this is that answer. I run it quarterly.”

The problem

Your Figma library says primary blue is #2563EB. Your codebase has seven different "primary blues" scattered across components. Nobody knows which is the source of truth.

The outcome

A concrete list of every hardcoded color, spacing value, and font size in the codebase that should be a token — with file paths and line numbers. Ready for a cleanup PR.

Tools used
ClaudeCursor

The workflow

What you need

  • Your repo, open in Cursor
  • Your tokens.json or equivalent design token file committed to the repo
  • (Optional) A recent Figma design system export

The prompt

In Cursor, open a new chat with your repo indexed. Paste:

You are auditing this codebase for design system compliance.

1. Read /tokens.json (or wherever our tokens live). Treat these as the source of truth for colors, spacing, typography, radii, and shadows.

2. Scan every .tsx, .ts, .css, and .scss file in /src.

3. For each hardcoded value you find that should be a token, return:
   - File path + line number
   - The hardcoded value (e.g. "#2563EB")
   - The closest matching token (e.g. "--color-primary-500: #2563EB")
   - A confidence score (high / medium / low)

4. Group results by category: colors, spacing, typography, other.

5. At the end, list the top 10 most-duplicated hardcoded values across the codebase. These are the ones worth fixing first.

Do not modify any code. Audit only.

What you do with the output

  • Sort by "most-duplicated" — fixing those gets you the highest coverage for the least effort
  • Walk through high-confidence matches first; accept or reject each
  • Low-confidence matches usually surface semantic drift (e.g. a "button-gray" that doesn''t have a token yet) — these become net-new tokens

When this is useful

  • Quarterly maintenance sweeps
  • Before a design system version bump
  • Onboarding a new designer who asks "what''s our actual color palette?"

When it breaks

  • If your tokens file is itself inconsistent, garbage in = garbage out
  • CSS-in-JS with dynamic values (styled-components template literals) is harder to parse than plain Tailwind or CSS variables