v0 Design Systems 2.0 wants your tokens. Here's the shape it expects
By The WAALEE Team · · 4 min read
v0 by Vercel shipped Design Systems 2.0 this year, and it's a real step up from the old flow of pasting a color into a prompt and hoping. You can now hand v0 a tailwind config, a globals.css file, and it will generate against your actual tokens instead of its defaults. The catch is in the fine print: v0's registry:theme approach assumes your tokens already follow the shadcn/ui CSS variable standard. Most brand sites, built in Webflow, Wix, WordPress, or a custom stack years before anyone said 'design system', don't have that file. They have a Figma file, or nothing written down at all.
What 'the shape it expects' actually means
shadcn's theming standard is specific: CSS custom properties on `:root` and `.dark`, named things like `--background`, `--primary`, `--radius`, consumed through Tailwind's `hsl(var(--primary))` pattern. It's a good standard, it's why shadcn components theme consistently. But it's a target shape, not a description of how most companies' brand colors already live in the world. If your source of truth is a brand PDF, a Figma file with color styles named 'Blue 1' and 'Blue 2', or just the hex codes your designer remembers, none of that drops into a registry:theme item without someone translating it first.
v0 will ask, which is the honest part
To its credit, v0's docs say Design Systems 2.0 doesn't require every source up front, if it needs more context it asks follow-up questions during import. That's the right failure mode, better than silently guessing a palette and shipping it. But it also means the import isn't really automatic for most teams. Someone still has to answer those questions correctly, which means someone still has to know the real values: the real hex codes, the real spacing scale, the real type ramp. If nobody in the room has that written down, v0 ends up asking questions nobody can answer precisely, and the import degrades back into best-guess defaults.
The same gap shows up in Figma's MCP server
Figma's Dev Mode MCP server has the same shape of requirement from the other direction. It can hand an agent the exact variable name behind a swatch, but only if your file uses Figma variables in the first place, and only if Code Connect is wired up to map those variables to real code syntax. A Figma file full of hardcoded hex values on shapes, no variables, gives the MCP server nothing precise to hand over either. Two different tools, same underlying problem: AI builders are getting genuinely better at consuming a design system. They're not getting better at inventing one that doesn't exist yet.
What actually closes the gap
- A tailwind config and globals.css in shadcn's CSS variable shape, ready to hand to v0 directly.
- Figma variables (not just styles) wired to Code Connect, so the MCP server can return real token names.
- Or tokens extracted straight from your live, shipped site, since that's the one place the real values already exist and match what customers see.
That third option is the shortcut worth knowing about. If your brand already lives on a real URL, in the actual computed colors, fonts, and spacing the browser renders, you don't have to reconstruct the tokens from memory or a stale brand deck. You extract them from the site itself.
Three ways to get from 'brand colors exist somewhere' to a file an AI builder can actually import:
- v0 Design Systems 2.0: Imports a tailwind config and globals.css directly and asks follow-up questions for what's missing. Fast once the file exists in shadcn's CSS variable shape, but it doesn't create that file for you.
- Figma Dev Mode MCP Server: Hands an agent exact variable names and code syntax, but only for files already using Figma variables with Code Connect set up. A file of hardcoded hex values returns nothing usable.
- WAALEE: Extracts real colors, type, and spacing straight from a live URL into W3C-shape tokens, so there's a shadcn-ready file to hand v0 (or any other builder) even when no design system was ever written down.
None of this is a knock on v0 or Figma. Both shipped exactly the right feature: consume tokens precisely if they exist, ask rather than guess if they don't. The work that's still on you is making sure the tokens exist in a shape the tool recognizes before you start the import, not after it's already generated three components in a palette that isn't yours.