V0 to respect existing tokens + components

[lfgraf (raf.works)]

TL;DR: I already have a design system in Figma (tokens + components). I want v0 to generate into that system—using my tokens and component library—so it doesn’t reinvent unstyled/brandless UI. What’s the best strategy you’ve used to make this stick?

Context

• I’m exploring v0 for a product and want it to be “style-aware.”

• Tokens + styles live in Figma (colors, type scale, spacing, radii, shadows).

• On the code side I’m using Tailwind + CSS variables + shadcn/radix-style primitives (happy to adapt if there’s a cleaner pattern).

Desired outcome

• v0 outputs import my components (e.g., import { Button } from “@/components/ui/button”), not raw HTML.

• All spacing/typography/colors come from my tokens (Tailwind theme or CSS vars).

• Zero inline styles. No ad-hoc classes that drift from the system.

What I’m thinking

1. Seed repo strategy

   • Provide v0 a starter repo that includes:

     • tokens.css (CSS vars) and/or tailwind.config.js with my tokens.

     • A documented component library (/components/ui/*) that wraps primitives and encodes variants.

     • ESLint/Stylelint rules to forbid inline styles + non-token color/spacing.

     • A short CONTRIBUTING.md with code “recipes” (e.g., “use for tertiary actions”).

   • Prompt v0 with “always import from /components/ui and use Tailwind tokens only.”

2. Few-shot component mapping

   • Give v0 examples like:

     • “When you need a primary CTAs, use .”

     • “Lists use ; tables use ; never DIY divs.”

   • Include 3–5 realistic patterns (card, form, table, modal, empty state) as reference.

3. Token sync

   • Export Figma tokens → JSON (Tokens Studio / Design Tokens plugin) → build CSS vars + Tailwind theme via Style Dictionary (or similar).

   • Keep a one-command sync (pnpm tokens:sync) so design changes flow through.

4. Guardrails

   • ESLint rule to ban style={{…}} and non-token colors.

   • CI check that fails on unknown classes or raw hex values.

   • (Optional) visual tests to catch drift.

Questions for folks who’ve done this

• What’s your most reliable way to make v0 consistently import your components instead of emitting raw markup?

• Have you had better results with CSS variables first (then Tailwind maps) vs Tailwind-only tokens?

• How do you pass the “component dictionary” to v0 so it learns that “button = @/components/ui/button with variants”?

• Any lightweight “lint rules” or codemods you use to auto-correct v0 output back into system-compliant code?

• If you’re using shadcn/radix: did you keep them as internal primitives and expose a branded layer, or let v0 touch shadcn directly?

• Bonus: examples of public repos or prompts that made this work reliably.

Happy to share back a minimal template (tokens → CSS vars + Tailwind, component wrappers, lint rules, and prompt snippets) once I firm up a good pattern.

Thanks!

[system]

Did you know there’s another category dedicated to v0 topics? A human should be here soon to help, but the answer may already be available even faster in one of these other posts.

Our docs are a great place to start.

What is v0? | v0 Docs

We also have a walkthrough to help guide your workflow.

Become a v0 expert

Getting Started Using v0 is like chatting with a frontend engineer, who takes in your design guidelines and creates an application for you. A common workflow with v0 is putting in design files and images to scaffold your application and then use text prompts to nudge v0 into creating your perfect application. Remember, just like any other AI tool, the quality of the output that v0 generates depends on the quality of the prompt or instructions you input. So, it’s important to be clear, descripti…

And these recordings can give you a look at v0 features and strategies in action shown by our Community:

https://community.vercel.com/tags/c/events/42/v0