# WAALEE > WAALEE (waalee.ai) turns any website or screenshot into a ready-to-use design system and AI-ready prompts, so sites built with AI builders (Lovable, v0, Bolt, Replit, Cursor, Claude) stop looking generic. Paste a URL or upload a design, and WAALEE extracts the real colors, typography, spacing and components, exports them as W3C design tokens and CSS variables, and writes prompts your builder can follow. WAALEE is a brand and venture of CIELO Agency LLC (Florida, United States). Made in Dubai. ## What it does - Reads a live website in a real headless browser (the rendered page, not a guess) or an uploaded file (PNG, JPG, WebP, GIF, HTML or CSS, up to 10 MB). - Extracts the design system: color palette with roles, font families and type scale, spacing scale, border radii, shadows and component patterns. - Exports W3C-compliant design tokens (JSON), CSS variables and a Tailwind theme, plus a downloadable bundle. - Writes AI prompts tuned for Lovable, v0, Bolt, Replit and Cursor to restyle an existing vibe-coded site or start a new one with the same look. - Checks accessibility basics such as color contrast. ## Who it's for - Founders and first-time site builders who use AI builders and want a site that looks designed, without design experience. - Developers and agencies who want a reference site's design system in code quickly. - Claude and other AI-agent users, through the WAALEE MCP server. ## How it works 1. Paste a site URL (or upload a screenshot/design) at https://waalee.ai. 2. WAALEE extracts the tokens in seconds. 3. Copy the prompt into your builder, or export the tokens/CSS. ## Pricing (US dollars) - Free: 3 extractions without an account, 5 in total with a free account. - Starter: $5/month, 5 extractions per month. - Unlimited: $45/month, unlimited extractions. Subscriptions can be cancelled any time from the Portal (Manage billing). Details: https://waalee.ai/pricing ## Use WAALEE inside Claude (MCP) - Add the MCP server: `claude mcp add --transport http waalee https://waalee.ai/api/mcp` - Or install the Claude skill: `curl -fsSL https://waalee.ai/onboard.mjs | node --input-type=module - onboard --yes` - Tools: extract_design (extract any URL), list_templates, get_template, list_projects. - MCP use counts toward the same plan limits. ## Other products - Website Builder (https://waalee.ai/build): paste a site whose style you like plus your own site or documents; WAALEE extracts the design, works out the ideal customer and funnel, writes the copy, and publishes a full on-brand website (export, Vercel deploy or web.waalee.ai). The style kit (tokens, Tailwind, CSS, prompts, style guide PDF) can be downloaded right after the first step. - Statics Creator (https://waalee.ai/statics): turns a website into on-brand ad graphics. - Full Website Rebuilder (beta, https://waalee.ai/rebuilder): copy, sales and funnel analysis. - Design style gallery (https://waalee.ai/design-styles) and free Resources & Elements (https://waalee.ai/resources). ## Key pages - Home: https://waalee.ai - Fix your vibe-coded site: https://waalee.ai/fix-your-vibe-coded-site - For first-time site builders: https://waalee.ai/first-time-site-builders - For enterprise and teams: https://waalee.ai/enterprise - For vibe coders: https://waalee.ai/vibe-coders - For agencies: https://waalee.ai/agencies - API + MCP: https://waalee.ai/mcp - Docs: https://waalee.ai/docs - Waalee 101 (beginner guide): https://waalee.ai/waalee-101 - Integrations: https://waalee.ai/integrations - Blog: https://waalee.ai/blog - Privacy: https://waalee.ai/privacy · Terms: https://waalee.ai/terms ## Contact hello@waalee.ai (support) · legal@waalee.ai (legal and privacy) --- # WAALEE answers > Direct answers to common questions about WAALEE, AI website builders, design systems, design tokens and making AI-built sites look on-brand. Each answer links to its source page. ## About WAALEE ### What is WAALEE? WAALEE (waalee.ai) turns any website or screenshot into a ready-to-use design system and AI-ready prompts. Paste a URL or upload a design and it extracts the real colors, typography, spacing, radii, shadows and component patterns from the rendered page, exports them as W3C design tokens, CSS variables and a Tailwind theme, and writes prompts for Lovable, v0, Bolt, Replit, Cursor and Claude so vibe-coded sites stop looking generic. Source: https://waalee.ai/ ### How much does WAALEE cost? Pricing in US dollars: Free gives 3 extractions without an account and 5 in total with a free account. Starter is $5 per month for 5 extractions a month. Unlimited is $45 per month for unlimited extractions. Cancel any time from the Portal. Source: https://waalee.ai/ ### Which AI builders does WAALEE work with? Lovable, v0, Bolt, Replit, Cursor and Claude. WAALEE writes a prompt tuned for each builder and exports tokens as JSON, CSS variables and a Tailwind theme that any stack can use. Source: https://waalee.ai/ ### Can I use WAALEE inside Claude or ChatGPT? Use WAALEE inside Claude, ChatGPT or Cursor through its MCP server at https://waalee.ai/api/mcp. In Claude Code: claude mcp add --transport http waalee https://waalee.ai/api/mcp. Tools: extract_design, list_templates, get_template and list_projects. Source: https://waalee.ai/ ### What do I get from an extraction? A color palette with roles, font families and type scale, spacing scale, border radii, shadows, component patterns, accessibility contrast checks, W3C design tokens, CSS variables, a Tailwind theme and AI prompts for your builder. Source: https://waalee.ai/ ## From the blog ### What is the best AI website builder in 2026? It depends on the job. For a simple hosted site, a no-code builder like Durable, Wix or Framer is fastest. For a product with logins and a database, an AI app builder like Lovable, Bolt, v0 or Replit. If you already have code, Cursor or Claude Code. Source: https://waalee.ai/blog/best-ai-website-builders-2026 ### Is there a free AI website builder? Most of the tools here have a free tier or a free trial. Free tiers usually limit how many messages or credits you get, or put the site on a subdomain. Check each tool's pricing page, because limits change often. Source: https://waalee.ai/blog/best-ai-website-builders-2026 ### Lovable vs Bolt vs v0: which should I use? All three turn a chat into a working React app. Lovable leans toward full apps with a backend, Bolt toward fast prototypes in the browser, and v0 toward UI components and Next.js on Vercel. Try the same prompt in two of them and keep the one you like working in. Source: https://waalee.ai/blog/best-ai-website-builders-2026 ### Do I own the code an AI website builder makes? With AI app builders and coding tools, yes: you can usually sync to GitHub or download the project. With most no-code builders, the site stays on their platform. Read the terms if ownership matters to you. Source: https://waalee.ai/blog/best-ai-website-builders-2026 ### Why does my AI-built website look generic? Because the AI had no design to follow, so it used its defaults: the same font, layout and gradient as everyone else. Give it a real spec (colors, fonts, spacing, components) taken from a site you like, and the output changes a lot. Source: https://waalee.ai/blog/best-ai-website-builders-2026 ### Can AI build a website that looks like another site I like? It can follow the same design style, if you give it that style as a spec instead of a description. WAALEE reads a live site and turns its colors, fonts and components into a prompt your builder can follow. Use it for inspiration and your own brand; don't copy someone's logo or content. Source: https://waalee.ai/blog/best-ai-website-builders-2026 ### Is vibe coding good enough for a real business website? For a marketing site or an early product, often yes. Have someone check forms, payments and security before you take real customer data, and keep the code somewhere you control. Source: https://waalee.ai/blog/best-ai-website-builders-2026 ### Why do AI-generated websites look generic? Because the AI fills every design decision you don't specify with its most common default. Same defaults, same site. Give it exact colors, fonts, spacing and layout and the output stops looking generic. Source: https://waalee.ai/blog/ai-websites-look-the-same-fixes ### How do I make my Lovable or Bolt site look better? Give it a design spec instead of adjectives: hex colors, named fonts, a corner radius, spacing values and a section order. Keep that spec in a file the tool reads on every prompt, and change one thing at a time. Source: https://waalee.ai/blog/ai-websites-look-the-same-fixes ### What are design tokens, in plain words? They're the exact values that make up a look: colors, font sizes, spacing, corner radius, shadows. Written down as names and values, so a person or an AI can reuse them the same way every time. Source: https://waalee.ai/blog/ai-websites-look-the-same-fixes ### What is "AI slop" design? A nickname for the default look AI tools produce when nobody guides them: the stock font, purple gradients, centered heroes, emoji icons and identical cards. It isn't broken, it's just everyone else's site. Source: https://waalee.ai/blog/ai-websites-look-the-same-fixes ### Do I need a designer to fix an AI-built site? Not always. References, a clear spec and a few rounds of focused prompts get most sites from generic to decent. For a brand identity (logo, voice, a distinctive system), a designer is still worth it. Source: https://waalee.ai/blog/ai-websites-look-the-same-fixes ### Can I copy another website's design with AI? Use other sites for inspiration and style, not as something to clone. Matching a feel (spacing, type scale, color mood) is normal design practice. Copying logos, images, text or a trademarked look is not. Source: https://waalee.ai/blog/ai-websites-look-the-same-fixes ## Article summaries ### VibeDesigner has 106 color palettes. None of them are yours VibeDesigner hands AI coding tools a preset design spec. DesignScan reads your actual site instead. Picking a style and extracting one aren't the same move. Read: https://waalee.ai/blog/vibedesigner-designscan-preset-vs-real-tokens (markdown: https://waalee.ai/blog/vibedesigner-designscan-preset-vs-real-tokens.md) ### Tokenbridge turns design choices into AI rules. You still write them Tokenbridge and brandkit-mcp both hand an AI coding tool your design rules. Neither one answers where those rules come from if you don't have them yet. Read: https://waalee.ai/blog/tokenbridge-brandkit-mcp-design-rules-source-gap (markdown: https://waalee.ai/blog/tokenbridge-brandkit-mcp-design-rules-source-gap.md) ### Superdesign's Claude Code skill can now extract your brand guide Superdesign's design skill ships an extract-brand-guide command that pulls colors and type straight from a URL. A real step forward, not a reason to skip dedicated extraction. Read: https://waalee.ai/blog/superdesign-claude-code-skill-brand-guide-extraction (markdown: https://waalee.ai/blog/superdesign-claude-code-skill-brand-guide-extraction.md) ### Vibe design: the newest fix for AI's generic UI problem Flowstep and VP0 design the screen before any code gets written, so AI apps stop looking the same. Neither one knows what your own brand looks like. Read: https://waalee.ai/blog/vibe-design-tools-flowstep-vp0-generic-ui-brand-gap (markdown: https://waalee.ai/blog/vibe-design-tools-flowstep-vp0-generic-ui-brand-gap.md) ### Perceptual color clustering: the design token bug no one talks about Most site-to-tokens extractors flatten five near-identical blues into noise. TokenScout and DesignDNA both tackle it differently. Here's what still needs a human eye. Read: https://waalee.ai/blog/color-clustering-design-token-extractors-designdna-tokenscout (markdown: https://waalee.ai/blog/color-clustering-design-token-extractors-designdna-tokenscout.md) ### Figma Console MCP exports tokens in 10 formats. It still needs Figma A community MCP server now exports Figma variables as DTCG 2025.10, CSS, Tailwind, SCSS and TS with zero build tools. Great news, if your system lives in Figma. Read: https://waalee.ai/blog/figma-console-mcp-dtcg-tokens-design-system-gap (markdown: https://waalee.ai/blog/figma-console-mcp-dtcg-tokens-design-system-gap.md) ### The best AI website builders in 2026 (and why they all look the same) Lovable, Bolt, v0, Framer, Wix, Durable and the rest, grouped by what they're actually for. Plus the one thing none of them do for you: give the site a real look. Read: https://waalee.ai/blog/best-ai-website-builders-2026 (markdown: https://waalee.ai/blog/best-ai-website-builders-2026.md) ### Why every AI website looks the same (and 9 fixes that work) Same font, same centered hero, same purple gradient. Here's why AI-built sites look generic, and nine practical fixes that work in Lovable, Bolt, v0, Cursor and Claude. Read: https://waalee.ai/blog/ai-websites-look-the-same-fixes (markdown: https://waalee.ai/blog/ai-websites-look-the-same-fixes.md) ### Dembrandt, StyleKit, WAALEE: picking a design token extractor A wave of free tools now pull colors, type and spacing straight off a live site. Here's what actually separates a CLI, a browser extension and WAALEE. Read: https://waalee.ai/blog/design-token-extractors-dembrandt-stylekit-compared (markdown: https://waalee.ai/blog/design-token-extractors-dembrandt-stylekit-compared.md) ### ux-skill kills AI slop with 152 rules. It still isn't your brand ux-skill's deterministic linter and 160 brand specs stop AI coding agents from shipping generic UI. The specs come from Apple, Linear and Stripe, not from your own site. Read: https://waalee.ai/blog/ux-skill-anti-ai-slop-linter-your-brand-gap (markdown: https://waalee.ai/blog/ux-skill-anti-ai-slop-linter-your-brand-gap.md) ### OpenAI dots: always-on AI agents are here. Your brand isn't in them OpenAI's new dots agents take on ongoing work, from proposals to working demos. Here's how fast agents are evolving, and why your design system has to be machine-readable now. Read: https://waalee.ai/blog/openai-dots-always-on-ai-agents-brand (markdown: https://waalee.ai/blog/openai-dots-always-on-ai-agents-brand.md) ### Anima MCP connects your AI agent to Figma. It still needs a system Anima's new MCP server pipes Figma components and tokens straight to Claude Code and Cursor. It only helps if a real design system already exists in Figma. Read: https://waalee.ai/blog/anima-mcp-figma-design-system-gap (markdown: https://waalee.ai/blog/anima-mcp-figma-design-system-gap.md) ### Chrome DevTools MCP gives agents real CSS. Not a design system Google's Chrome DevTools MCP now hands Claude Code and Cursor an element's exact CSS cascade. It answers one element at a time, not what a whole site's palette is. Read: https://waalee.ai/blog/chrome-devtools-mcp-css-styles-design-system-gap (markdown: https://waalee.ai/blog/chrome-devtools-mcp-css-styles-design-system-gap.md) ### Claude Design's web capture reads your site. Not its exact tokens Anthropic's Claude Design can now pull colors and fonts straight from a live URL. Read the docs closely and it's extracting your brand's feel, not its exact values. Read: https://waalee.ai/blog/claude-design-web-capture-exact-tokens-gap (markdown: https://waalee.ai/blog/claude-design-web-capture-exact-tokens-gap.md) ### Figma's Code to Canvas sends your UI to Figma, not your real brand Figma and Anthropic's Code to Canvas turns a running Claude Code build into editable Figma layers. It still assumes that build's colors and type were already yours. Read: https://waalee.ai/blog/figma-code-to-canvas-claude-code-brand-tokens-gap (markdown: https://waalee.ai/blog/figma-code-to-canvas-claude-code-brand-tokens-gap.md) ### Webflow's new Assets agent needs your brand variables already set Webflow's Assets, built on its Vidoso acquisition, generates on-brand creative by reading your design system and brand variables. If those don't exist yet, there's nothing for it to read. Read: https://waalee.ai/blog/webflow-assets-vidoso-brand-variables-gap (markdown: https://waalee.ai/blog/webflow-assets-vidoso-brand-variables-gap.md) ### Bolt.new's Design System Agents assume you already have one Bolt.new and Replit both shipped agents that reuse an existing design system faithfully. Neither one extracts tokens from a live site that never had one. Read: https://waalee.ai/blog/bolt-replit-design-system-agents-source-gap (markdown: https://waalee.ai/blog/bolt-replit-design-system-agents-source-gap.md) ### Webflow's AI Site Builder makes a design system. Not your brand's Webflow's AI Site Builder generates a full token system from a prompt. Brand references get approximated, not copied, and it can't read a site built outside Webflow. Read: https://waalee.ai/blog/webflow-ai-site-builder-design-tokens-gap (markdown: https://waalee.ai/blog/webflow-ai-site-builder-design-tokens-gap.md) ### Lovable shipped Design Systems. It still can't see your brand Lovable's new Design Systems feature lets teams reuse one system across projects. None of its three ways to build one read tokens off a live URL. Read: https://waalee.ai/blog/lovable-design-systems-feature-brand-gap (markdown: https://waalee.ai/blog/lovable-design-systems-feature-brand-gap.md) ### Google open-sourced DESIGN.md. Here's what's actually in the spec Google Labs made its DESIGN.md format open source and Apache-2.0 licensed. It's a real spec now, not a convention. Here's what changed and what still has to be filled in by hand. Read: https://waalee.ai/blog/google-design-md-open-source-spec (markdown: https://waalee.ai/blog/google-design-md-open-source-spec.md) ### Claude Code Skills can extract your design system now. Here's the catch A growing marketplace of Claude Code Skills promises to pull design tokens straight from a URL or codebase. Great, if you already have Claude Code installed and open. Read: https://waalee.ai/blog/claude-code-skills-design-system-extraction (markdown: https://waalee.ai/blog/claude-code-skills-design-system-extraction.md) ### v0 Design Systems 2.0 wants your tokens. Here's the shape it expects v0's Design Systems 2.0 will import your tailwind config and globals.css directly. The catch: it assumes shadcn/ui's CSS variable standard, and most sites don't have that file yet. Read: https://waalee.ai/blog/v0-design-systems-2-token-shape (markdown: https://waalee.ai/blog/v0-design-systems-2-token-shape.md) ### Style Dictionary v5 shipped. Three things quietly broke your tokens Style Dictionary v5 needs Node 22, tightens what a reference can point to, and zeroheight just retired its legacy export. Here's what actually changes in your pipeline. Read: https://waalee.ai/blog/style-dictionary-v5-breaking-changes (markdown: https://waalee.ai/blog/style-dictionary-v5-breaking-changes.md) ### Cursor's Design Mode fixes precision. Not your default palette Cursor's Design Mode lets you click, draw, or talk an agent through a UI fix on a live page. It's a real upgrade for iteration. It still starts every first draft from Cursor's own defaults. Read: https://waalee.ai/blog/cursor-design-mode-precision-not-palette (markdown: https://waalee.ai/blog/cursor-design-mode-precision-not-palette.md) ### shadcn's new MCP server fixes hallucinated components. Not your theme shadcn/cli v4 shipped an MCP server and shareable presets in 2026. Agents stopped inventing components that don't exist. The look is still whichever preset you picked. Read: https://waalee.ai/blog/shadcn-mcp-server-not-your-theme (markdown: https://waalee.ai/blog/shadcn-mcp-server-not-your-theme.md) ### Tailwind v4 killed the JS config. Your AI builder still guesses Tailwind v4 moved tokens into a CSS-first @theme block and switched to OKLCH. That fixed one problem and left the default-palette problem untouched. Read: https://waalee.ai/blog/tailwind-v4-theme-tokens-for-ai-builders (markdown: https://waalee.ai/blog/tailwind-v4-theme-tokens-for-ai-builders.md) ### Why every AI-coded app looks like shadcn/ui (and the real fix) shadcn/ui is now the default kit for Claude, Lovable, v0, Cursor and Bolt. That's why so many AI apps share one look. Here's what actually breaks the pattern. Read: https://waalee.ai/blog/why-ai-apps-look-like-shadcn (markdown: https://waalee.ai/blog/why-ai-apps-look-like-shadcn.md) ### Figma's MCP server only works if you own the Figma file Figma's Dev Mode MCP server feeds real tokens straight into Claude Code and Cursor. Great, if you have access to the file. Here's the fix when you don't. Read: https://waalee.ai/blog/figma-mcp-server-without-a-figma-file (markdown: https://waalee.ai/blog/figma-mcp-server-without-a-figma-file.md) ### The W3C design tokens spec just went stable, and hex codes broke DTCG 2025.10 is the first stable Design Tokens Format Module. It also changes how color values are written. Here's what actually changed. Read: https://waalee.ai/blog/dtcg-2025-color-format-change (markdown: https://waalee.ai/blog/dtcg-2025-color-format-change.md) ### How to extract a full design system from any website in 60 seconds Point at a URL, get colors, type, spacing, components, and AI-ready prompts. Here's exactly what happens under the hood. Read: https://waalee.ai/blog/extract-a-design-system-in-60-seconds (markdown: https://waalee.ai/blog/extract-a-design-system-in-60-seconds.md) ### Vibe coding is great — until it needs to look designed AI builders ship working UIs fast. Making them look intentional is a different skill. Here's the bridge. Read: https://waalee.ai/blog/vibe-coding-until-it-needs-to-look-designed (markdown: https://waalee.ai/blog/vibe-coding-until-it-needs-to-look-designed.md) ### Design tokens, explained: the language your AI actually understands Colors and fonts are the obvious part. The real power is naming decisions so a machine can apply them consistently. Read: https://waalee.ai/blog/design-tokens-explained (markdown: https://waalee.ai/blog/design-tokens-explained.md) ### From screenshot to style guide: reverse-engineering great design A practical look at how to deconstruct a site you admire into a system you can actually build with. Read: https://waalee.ai/blog/screenshot-to-style-guide (markdown: https://waalee.ai/blog/screenshot-to-style-guide.md) ### Why your AI-generated site looks generic (and how to fix it) Five tells of default AI design — and the one input that removes all of them at once. Read: https://waalee.ai/blog/why-your-ai-site-looks-generic (markdown: https://waalee.ai/blog/why-your-ai-site-looks-generic.md) ### The anatomy of a $100M landing page What the best-funded startups actually do above the fold — and how to lift the pattern, not the pixels. Read: https://waalee.ai/blog/anatomy-of-a-100m-landing-page (markdown: https://waalee.ai/blog/anatomy-of-a-100m-landing-page.md) ### Colors, type, spacing: what to actually steal from sites you admire A short field guide to the three things worth extracting — and the things that don't transfer. Read: https://waalee.ai/blog/what-to-steal-colors-type-spacing (markdown: https://waalee.ai/blog/what-to-steal-colors-type-spacing.md) ### How to rebuild any site 1:1 with Claude, Lovable, or v0 A repeatable workflow: extract, hand the tokens to your builder, and reconstruct the exact look and feel. Read: https://waalee.ai/blog/rebuild-any-site-with-ai (markdown: https://waalee.ai/blog/rebuild-any-site-with-ai.md) ### W3C design tokens: exporting a system your whole team can use One portable file that Figma, your codebase, and your AI builder all understand. Read: https://waalee.ai/blog/w3c-design-tokens-for-your-team (markdown: https://waalee.ai/blog/w3c-design-tokens-for-your-team.md) ### Turning inspiration into production: a practical workflow The end-to-end path from "I love this site" to shipped, on-brand code — without the guesswork. Read: https://waalee.ai/blog/turning-inspiration-into-production (markdown: https://waalee.ai/blog/turning-inspiration-into-production.md) --- # VibeDesigner has 106 color palettes. None of them are yours > VibeDesigner hands AI coding tools a preset design spec. DesignScan reads your actual site instead. Picking a style and extracting one aren't the same move. Source: https://waalee.ai/blog/vibedesigner-designscan-preset-vs-real-tokens Published: 2026-10-15 · 4 min read · By The WAALEE Team Topics: VibeDesigner AI design presets, design token extractor MCP server, DesignScan extractor, AI website builder color palette, fix generic AI website design, design tokens for Cursor Lovable Bolt v0 Two small tools landed in the same lane this month, both trying to stop Cursor, Bolt, Lovable and v0 from inventing a look on the spot. [VibeDesigner](https://www.hunted.space/product/vibedesigner) hands the agent a design spec picked from a library: page type, style, palette, exported as exact CSS values. [DesignScan](https://socket.dev/npm/package/@designscan/extractor), a local npm package and MCP server, does something that sounds similar but isn't: it reads the computed styles off a URL you give it and turns those into the same kind of token file. One is a style you choose. The other is a style you already have. Worth being clear on which problem each one actually solves, because they don't solve the same one. ## VibeDesigner: pick a style, get a spec VibeDesigner's pitch, per its own [Product Hunt listing](https://www.hunted.space/product/vibedesigner), is a library of 10 page types, 18 design styles and 106 color palettes. You pick combinations close to what you want, and it generates a design spec with exact CSS tokens, colors, spacing, type, ready to paste straight into Cursor, Bolt, Lovable or v0. That's a real fix for the blank-prompt problem: instead of typing "make it modern and clean" and letting the model guess, you're handing it concrete values up front. The agent stops inventing a purple gradient because you already told it exactly what to use. ## DesignScan: point it at a URL, read what's actually there DesignScan runs as a local MCP server, added with a plain `claude mcp add designscan -- npx -y @designscan/extractor`, no API key, nothing leaves your machine. Its npm listing describes the flow as URL in, design tokens out, normalized into a DESIGN.md, W3C JSON, or CSS variables, whichever format the agent or the rest of your pipeline expects. It also reports extraction warnings, a bot challenge blocking the page, a site that renders almost nothing without JavaScript, so the agent knows when a read came back thin instead of silently trusting a broken scrape. The output format looks a lot like VibeDesigner's spec file. The input is the opposite: not a choice from a library, a reading of a page that already exists. - VibeDesigner: 106 preset palettes and 18 styles, combined into a spec. The values are real CSS, but they belong to whoever built the preset library, not to you. - DesignScan: reads computed styles off a live URL, locally, with warnings when the read is unreliable. The values are real because they came off your actual page. - Both output the same kind of thing in the end, tokens an agent can paste in instead of guessing. Only one of them is describing a brand that already exists. ## A preset is still someone's choice, just not yours Here's the part worth sitting with. A palette from a library of 106 is still a real, deliberate color choice, someone thought about contrast and mood when they built it. That's genuinely better than a model's default gradient. But it's also not your brand any more than a Dribbble screenshot is. If you already have a site, a logo, a Figma file, anything with your actual colors and type in it, starting from a preset means throwing that away and borrowing someone else's taste instead of using your own. VibeDesigner is the right tool when you're starting from nothing and need a decent-looking starting point fast. It's the wrong tool the moment you already have a brand to be consistent with. ## When extraction is the right call instead DesignScan's whole premise only works when there's a real page to point it at. A founder redesigning an existing product, a team matching a new feature to a site that's already live, anyone who wants the new thing to look like the old thing rather than like a fresh preset, that's the case for reading instead of picking. The tradeoff is the one DesignScan is honest about in its own warnings: a page behind a bot check or one that renders nothing without JavaScript gives you a bad read, and a bad read that gets treated as good is worse than no read at all. Three ways to get design values in front of an AI coding tool, depending on whether you're starting fresh or matching something that already exists: - [VibeDesigner](https://www.hunted.space/product/vibedesigner): Library of 10 page types, 18 styles and 106 color palettes, combined into a CSS spec for Cursor, Bolt, Lovable or v0. No site required, but the values aren't yours. - [DesignScan](https://socket.dev/npm/package/@designscan/extractor): Local npm package and MCP server. Reads computed styles off a real URL, outputs DESIGN.md, W3C tokens or CSS, with warnings when a page didn't read cleanly. - [WAALEE](https://waalee.ai/): Paste a live URL and get real colors, type and spacing back as W3C tokens and AI-ready prompts already shaped for Claude, Lovable, v0, Cursor and Bolt, no library to pick from. Neither tool here is doing anything wrong. A preset library turns a blank page into a decent one fast, and a local extractor that warns you when its own read is shaky is more honest than most tools in this space. The question to ask before opening either one is simple: does a version of this brand already exist somewhere I can point a tool at, or am I actually starting from zero. If it's the first, read it. If it's the second, a good preset beats a bad guess every time. --- # Tokenbridge turns design choices into AI rules. You still write them > Tokenbridge and brandkit-mcp both hand an AI coding tool your design rules. Neither one answers where those rules come from if you don't have them yet. Source: https://waalee.ai/blog/tokenbridge-brandkit-mcp-design-rules-source-gap Published: 2026-10-13 · 4 min read · By The WAALEE Team Topics: AI-readable design rules, design tokens for Cursor, Tokenbridge design configurator, brandkit-mcp, design system MCP server, fix generic AI coding output Two new tools landed in the same lane this year, both trying to stop AI coding agents from inventing a brand on the spot. [Tokenbridge](https://www.hunted.space/product/tokenbridge) is a visual configurator that turns your design choices into rules Cursor, Copilot and Windsurf can read. [brandkit-mcp](https://github.com/ejwhite7/brandkit-mcp) is an open-source MCP server that exposes a company's whole brand system, visual and verbal, straight to Claude. Both are useful. Neither one asks the question that actually decides whether they help you: where do your design choices come from if nobody wrote them down yet. ## Tokenbridge: fill in a form, get six export formats Tokenbridge's maker, Austin Gao, built it after getting tired of fixing AI-generated styles by hand, per his own [Product Hunt launch](https://www.hunted.space/product/tokenbridge). It's a visual configurator: you set your colors, type and spacing in a UI, and it exports AI-readable design rules in six formats aimed at the tools people actually use, Cursor, Copilot, Antigravity, Windsurf. Configure once, export everywhere, let the agent read the rules instead of guessing. That's a real fix for a real problem, assuming you already know what to type into the configurator. ## brandkit-mcp: your whole brand, served to Claude over MCP brandkit-mcp goes wider. It's an MCP server, installable with a plain `npx -y brandkit-mcp`, that exposes what its docs call a company's "brand atomic system": not just colors and type but verbal identity too, tone, voice, the words you use. It ships with an init command that scaffolds a starter template and, per its npm listing, 18 tools and 14 resources an agent can call directly. That's a meaningfully different shape than Tokenbridge: instead of exporting a static rules file, it answers a live query from Claude every time the agent needs to check what the brand voice sounds like. - Tokenbridge: a visual form you fill in once, exported to 6 static rule formats for Cursor, Copilot, Antigravity and Windsurf. - brandkit-mcp: an open-source MCP server, queried live by Claude and other agents, covering both visual and verbal brand identity. - Both assume the brand already exists somewhere in your head or on a slide, ready to be typed in or scaffolded by hand. - Neither one reads a website. If your brand only exists as a shipped site, there's nothing to configure or scaffold from yet. ## The step before the form Here's who actually hits a wall with both tools. A founder who paid a freelancer for a site eight months ago and never got a style guide back. A team whose brand lives in a Figma file nobody's touched since the last redesign. Anyone sizing up a competitor's site for inspiration, where there's no form to fill in because it isn't your brand to configure. For all of them, the honest first move with Tokenbridge or brandkit-mcp is: open DevTools, start guessing at hex codes, and hope you get close. That's the exact manual work both tools were built to replace downstream, just moved one step earlier. ## Read the live page instead of typing from memory A shipped website already is the design system, computed: real colors, real type, real spacing, just not written down anywhere an AI tool can read yet. Point an extractor at the URL instead of a blank form and you skip the part where you have to already know your own hex codes. The output can still feed a Tokenbridge-style rules file or an MCP server like brandkit-mcp; it just starts from something real instead of your best guess. Three ways to get your design rules in front of an AI coding tool, depending on whether you're starting from a brand you can describe or a site you'd have to eyeball: - [Tokenbridge](https://www.hunted.space/product/tokenbridge): Visual configurator for design tokens, exported to 6 AI-readable formats for Cursor, Copilot, Antigravity and Windsurf. You type in the values yourself. - [brandkit-mcp](https://github.com/ejwhite7/brandkit-mcp): Open-source MCP server exposing a brand's visual and verbal identity live to Claude and other agents. Scaffolded by hand with an init command, not extracted. - [WAALEE](https://waalee.ai/): Paste a live URL and get the real colors, type and spacing back as W3C tokens and AI-ready prompts for Claude, Lovable, v0, Cursor and Bolt, no form to fill in first. None of this is a knock on either tool. A configurator that exports to six formats and an MCP server that serves brand voice live are both doing real work, and if your brand is already written down somewhere, use them. The question worth asking before you open either one is simpler than it sounds: do I actually have my design system typed up anywhere, or am I about to reverse-engineer my own site from memory to fill in someone else's form. --- # Superdesign's Claude Code skill can now extract your brand guide > Superdesign's design skill ships an extract-brand-guide command that pulls colors and type straight from a URL. A real step forward, not a reason to skip dedicated extraction. Source: https://waalee.ai/blog/superdesign-claude-code-skill-brand-guide-extraction Published: 2026-10-11 · 4 min read · By The WAALEE Team Topics: Superdesign Claude Code skill, extract brand guide from URL, design system extraction tool, Claude Code design skill, AI coding agent design tokens, Superdesign vs WAALEE Superdesign started as a VS Code extension for generating UI mockups on a canvas. The current version is a skill: install it into Claude Code, Cursor, or basically any coding agent, and it adds a design workflow on top of whatever you're already building. The part worth noticing this week is the CLI underneath it now ships an `extract-brand-guide` command that takes a plain URL and returns colors, type and spacing back to the agent. That's the same job a dedicated extraction tool does, built directly into a design skill millions of Claude Code users are already installing. ## What the skill actually does [Superdesign](https://superdesign.dev/) sets up a design system inside your own codebase, then generates and iterates UI drafts on an infinite canvas before any of it becomes final code, closer to a design tool bolted onto your agent than a one-shot prompt. Its documentation describes `extract-brand-guide` as pulling a reference's palette and typography straight from a URL, which means the skill can ground a new screen in a real brand without you manually typing in hex codes first. For a tool built around rapid UI iteration, that's a sensible feature to add. It removes one manual step in the exact workflow the skill already owns. ## A feature inside a tool is not the same as a tool for the job Here's the catch. `extract-brand-guide` exists to feed Superdesign's own canvas, so its output is shaped for that one consumer. If what you actually want is a clean, portable set of W3C design tokens you can hand to Lovable one week and Cursor the next, or a DESIGN.md you check into a repo that no agent owns, a feature bundled inside a design skill is the wrong shape for the job even when the underlying extraction logic is solid. [jezweb's design-system skill](https://claudemarketplaces.com/skills/arvindrk/extract-design-system/extract-design-system) runs into the same issue from the other direction: it's a Claude Code skill built specifically to analyze a site or screenshot and write a DESIGN.md, which is more portable than Superdesign's bundled version, but it still only runs inside Claude Code, and only when you remember to invoke it. - Superdesign: a full design-and-iterate workflow with brand extraction as one command inside it. Best if you're already living on its canvas. - jezweb design-system skill: a focused Claude Code skill that extracts tokens into a DESIGN.md. Portable output, but Claude Code-only and skill-install-dependent. - Both assume you're already inside a specific agent or workflow before extraction even starts. ## Where extraction should actually live The fact that three different tools have now independently decided to bolt URL-to-tokens extraction onto themselves (a design canvas, a Claude Code skill, and others before them) says something: extraction is infrastructure, not a feature any single tool should own. A brand's palette and type scale don't belong to Claude Code any more than they belong to Cursor or Lovable. The moment you extract them, you want to reuse that exact token set across all four, not re-run a different vendor's extractor inside each one and hope they agree with each other down to the hex code. Three ways to pull real brand values out of a reference right now, depending on where you want that output to live: - [Superdesign](https://superdesign.dev/): Design skill for Claude Code, Cursor and others. extract-brand-guide pulls colors and type from a URL to feed its own canvas workflow. Great if you're already drafting UI there. - [jezweb design-system skill](https://claudemarketplaces.com/skills/arvindrk/extract-design-system/extract-design-system): Claude Code skill that extracts tokens from a site or screenshot into a DESIGN.md. Portable file, but Claude Code-only and has to be installed and invoked. - [WAALEE](https://waalee.ai/): Paste a live URL once, get the real colors, type and spacing back as W3C tokens and AI-ready prompts for Claude, Lovable, v0, Cursor and Bolt, no skill install, no single agent required. None of this makes Superdesign's new command a bad idea. Built-in extraction beats no extraction, and if your whole workflow already happens inside its canvas, using its own command is the path of least resistance. But the second you want the same brand to show up correctly in more than one tool, the question changes from "does this agent have an extraction feature" to "where does my team keep the one token set every agent reads from." That answer should live outside any single coding agent, not bundled inside the one you happened to install first. --- # Vibe design: the newest fix for AI's generic UI problem > Flowstep and VP0 design the screen before any code gets written, so AI apps stop looking the same. Neither one knows what your own brand looks like. Source: https://waalee.ai/blog/vibe-design-tools-flowstep-vp0-generic-ui-brand-gap Published: 2026-10-09 · 5 min read · By The WAALEE Team Topics: vibe design, vibe design tools, AI UI generic problem, Flowstep AI design platform, VP0 design library, fix generic AI website Vibe coding's generic-look problem is old news by now: ask Claude, Lovable or v0 for an app with no reference and no tokens, and you get the same rounded cards, the same purple-to-blue gradient, the same Inter typeface everyone else got. The newer twist is a category calling itself "vibe design": tools that design the screen first, before a single line of code gets written, on the theory that the generic look is a prompting problem you can solve earlier in the pipeline instead of patching after the fact. Worth a look, because the theory is half right. ## Flowstep's bet: generate the design, not the code [Flowstep](https://flowstep.ai/), a Tallinn startup that raised $2.6M to build what it calls an "AI-native design platform," frames vibe design as the visual counterpart to vibe coding. You describe a product, optionally paste in a PRD, a reference image or a link, and it generates multiple screens and flows on an infinite canvas you can still edit by hand before anything ships. From there you export to Figma for a design team or straight to code for a dev. The pitch is that a coding agent prompted straight from text has to invent layout, spacing and hierarchy on the spot; a coding agent handed an already-designed screen just has to implement it. ## VP0's bet: hand the agent a screen that already exists [VP0](https://vp0.com/) takes a narrower, more mechanical version of the same idea for iOS apps specifically. It's a free library of finished mobile screen designs; you pick one close to what you want, copy its link, and paste that into Cursor, Claude Code or Lovable. Because each screen has a clean, AI-readable source structure, the agent rebuilds it in SwiftUI or React Native instead of guessing at a layout from an adjective-heavy prompt. VP0's own framing is blunt about why this exists: a blank prompt forces the model to invent every visual decision, and the result is the bland default every AI app shares. - Flowstep: text, images or a PRD in, multiple editable screens and flows out, on a canvas, exportable to Figma or code. General-purpose, web and app. - VP0: pick an existing, finished iOS screen from a free library and hand its link to your coding agent to rebuild. Narrower, faster, mobile-only. - Both move the "what should this look like" decision earlier, out of the coding agent's lap and into a design step that happens first. - Neither one reads an existing brand. Flowstep invents a new look from your prompt; VP0 hands you someone else's already-finished look. ## Designing first still isn't the same as designing yours Here's the gap. Moving the design decision earlier in the pipeline fixes the specific failure mode where a coding agent, given zero visual direction, falls back on training-data averages, the generic look. It doesn't fix the brand problem, because neither tool is pulling from your brand to begin with. Flowstep's canvas still generates a new aesthetic from its own model's sense of good design, which is more intentional than a bare prompt but still not your company's actual palette, type scale or spacing rhythm. VP0's library solves generic in a different way: every app built from the same screen link inherits that screen's look, which is consistent, but it's VP0's look, not yours. A design-first step helps most when the thing it's designing is actually sourced from somewhere real; a screen or flow generated from scratch is just a better-organized version of the same guess. ## Where real tokens still matter more If you already have a brand, a live site, or even just a reference you love, the fastest route to a screen that looks like you isn't a new canvas inventing one from a text prompt, it's handing the coding agent your actual colors, type and spacing up front, the same way VP0 hands it a screen, except the screen is built from your own system instead of a stranger's. Vibe design tools and token extraction aren't competitors so much as two different places to spend the same effort: design a brand-new screen fast, or ground the screen in a brand that already exists. Three ways to get a less generic screen out of an AI coding tool, depending on whether you're designing from scratch or already have a brand: - [Flowstep](https://flowstep.ai/): AI-native design canvas. Generates editable multi-screen flows from a prompt, PRD, image or link; exports to Figma or code. Invents a new look, doesn't read an existing brand. - [VP0](https://vp0.com/): Free library of finished iOS screens. Paste a screen's link into Claude Code, Cursor or Lovable and it rebuilds that exact design in SwiftUI or React Native. Mobile-only, and the look is VP0's, not yours. - [WAALEE](https://waalee.ai/): Paste your own live URL (or a reference site) and get its real colors, type and spacing back as W3C tokens and AI-ready prompts for Claude, Lovable, v0, Cursor and Bolt, grounded in a brand that actually exists. Both categories are a real improvement on the "just prompt it and hope" default, and designing before coding is the right instinct regardless of where the design comes from. But if the goal is a site or app that looks like your company and not like a well-made placeholder, the question to ask before opening any of these tools is the same one: where are the actual values coming from. A canvas that invents a fresh look and a library that hands you someone else's both skip that question. Starting from your own real tokens doesn't. --- # Perceptual color clustering: the design token bug no one talks about > Most site-to-tokens extractors flatten five near-identical blues into noise. TokenScout and DesignDNA both tackle it differently. Here's what still needs a human eye. Source: https://waalee.ai/blog/color-clustering-design-token-extractors-designdna-tokenscout Published: 2026-10-07 · 5 min read · By The WAALEE Team Topics: design token extractor, perceptual color clustering, extract color palette from website, DTCG design tokens, design tokens for AI coding agents, DesignDNA vs TokenScout Pull the colors off almost any real website with a naive extractor and you get garbage back. Not wrong-garbage, too-much-garbage: forty blues that are all basically the same blue, because a button's hover state, its focus ring and its disabled state each render at a slightly different hex. A palette like that is useless to hand to Claude or Cursor. It's also the default output of most tools in this space until very recently, and it's the quiet reason a lot of "extracted design systems" still look wrong once an AI coding agent builds from them. ## Why raw computed styles lie A browser's computed-style API will happily report `#2563EB`, `#2563EC` and `#2462EA` as three distinct colors, because they are, technically. To a human eye looking at the rendered page, they're one blue with rounding noise from opacity layers, box-shadows, and anti-aliasing. Average a page's styles without correcting for that and your "brand palette" balloons to 60+ swatches, most of them duplicates with no semantic meaning. Feed that straight into a prompt and the AI has no idea which blue is actually the brand's primary action color. ## Two tools solving it two different ways [TokenScout](https://github.com/Atroci/tokenscout), a newer open-core CLI and MCP server from developer Hugo Carvalho, attacks this head-on. Per its own release notes, it converts every sampled color from sRGB to CIELAB space and clusters them using the ΔE76 perceptual distance formula, the same math color scientists use to decide whether two colors are distinguishable to a human eye at all. Colors within a tight ΔE76 threshold get merged into one token; the rest survive as genuinely distinct brand colors. It does the same kind of reduction for type and spacing scales, so a page with 14 subtly different `font-size` values comes back as the 5 or 6 that are actually a deliberate scale. [DesignDNA](https://chromewebstore.google.com/detail/aminpdcpfgoncbefdaemiabmalfckfcd), a Chrome and Firefox extension, goes wider instead of deeper on the same problem: one click on an open tab and it extracts colors, type, spacing, shadows and components, then hands back W3C tokens, CSS variables, a Tailwind v4 theme, and Figma-importable styles, plus an interactive page showing every extracted style rendered live so you can sanity-check it by eye before trusting it. It doesn't publish the clustering math TokenScout does, but the live-preview step is its answer to the same trust problem: let a human catch the duplicate-blue issue visually, fast, instead of hoping the algorithm nailed it. - Naive extraction: every computed style value becomes a token. Dozens of near-duplicate colors, no signal. - TokenScout's approach: CIELAB + ΔE76 clustering collapses perceptually identical colors before they ever reach the token file. - DesignDNA's approach: wide extraction across colors, type, spacing and components, with a live visual review step to catch what the algorithm missed. - Either way, the goal is the same: a palette small enough and clean enough that an AI coding agent can actually reason about which color means what. ## What clustering still can't tell you Collapsing near-duplicate blues into one token is a math problem, and both tools above are solving it well. Knowing that this particular blue is the primary CTA color and that other blue is just a disabled-state tint, while both survive clustering as technically distinct, is a judgment problem. No distance formula knows which color your team actually treats as "the brand color" versus an incidental one that happens to appear often. That's still the part a person checks, whichever extractor hands you the cleaned-up list. Three ways to get a usable color palette and token set out of a live site right now: - [TokenScout](https://github.com/Atroci/tokenscout): Open-core CLI and MCP server. Clusters colors with CIELAB ΔE76 perceptual distance before exporting DTCG JSON, CSS variables and Tailwind config. Best for teams who want the math done for them. - [DesignDNA](https://chromewebstore.google.com/detail/aminpdcpfgoncbefdaemiabmalfckfcd): Free Chrome/Firefox extension. One click extracts colors, type, spacing, shadows and components, with a live visual preview to catch extraction errors by eye. - [WAALEE](https://waalee.ai/): Paste a live URL and get a cleaned-up palette plus full type, spacing and W3C tokens back as AI-ready prompts already shaped for Claude, Lovable, v0, Cursor and Bolt. ## The output format was never the hard part Every tool in this space now speaks DTCG, Tailwind config and CSS variables. That convergence is good, but it was always the easy half of the problem. The hard half is turning raw computed styles into a palette small enough and accurate enough that an AI agent builds consistent UI from it instead of inventing a slightly different shade of blue on every new component. Clustering gets you most of the way there. A quick visual check gets you the rest. Skip both and you're just handing your coding agent the same mess you started with, formatted more neatly. --- # Figma Console MCP exports tokens in 10 formats. It still needs Figma > A community MCP server now exports Figma variables as DTCG 2025.10, CSS, Tailwind, SCSS and TS with zero build tools. Great news, if your system lives in Figma. Source: https://waalee.ai/blog/figma-console-mcp-dtcg-tokens-design-system-gap Published: 2026-10-05 · 4 min read · By The WAALEE Team Topics: Figma Console MCP, design tokens export, DTCG 2025.10, Figma MCP server, extract design tokens without Figma, AI coding agent design system [Figma Console MCP](https://github.com/southleft/figma-console-mcp) just shipped one of the more useful things to land in the design-tokens-for-AI space this year: a `figma_export_tokens` tool with ten fully implemented output formats, DTCG JSON, CSS, Tailwind v3 and v4, SCSS, TypeScript, and more, with zero third-party build-tool dependencies. Pair that with the bidirectional `figma_import_tokens` sync it added for round-tripping code changes back into Figma variables, and you've got something that genuinely replaces a Style Dictionary pipeline for a lot of teams. It's a solid piece of engineering. It also runs on the same assumption every Figma-token tool has run on since this category started: the tokens already exist, as variables, in a Figma file someone maintains. ## What it actually does well Per the project's own [changelog](https://github.com/southleft/figma-console-mcp/blob/main/CHANGELOG.md), the latest release speaks DTCG 2025.10 on request, with the legacy hex dialect as the default for backward compatibility, and applies a full diff plan on import: creates, renames, alias re-targeting, replace-gated deletes. That's a real round-trip, not a one-way export. If your team already has a component library with properly structured variables in Figma, this tool turns "ask a designer to export tokens" into something Claude Code or Cursor can call directly over MCP, no manual hand-off, no stale JSON file sitting in a repo from three months ago. ## The step before step one None of that helps if there's no Figma file to point it at. Most companies past their first few months don't have a maintained token library in Figma. They have a shipped website. Maybe a Figma file exists somewhere, started by a contractor, abandoned after launch, missing half the components that shipped since. Pointing an MCP server at that file gets you variables that don't match what's actually live. The real design system, the one customers see, is sitting in the rendered page, not the design tool. - A founder who hired a no-code builder or a freelancer and never got a Figma file back. - A team whose Figma library drifted out of sync with the live site two redesigns ago. - Anyone benchmarking a competitor's site, where there's no file to request access to. - A rebrand where the new site shipped before the design system was ever formalized anywhere. ## Read the rendered page instead A live site is the same system, computed. Fonts resolved, colors rendered, spacing laid out in actual pixels, just without a Figma variable name attached to any of it. Point a tool at the URL instead of the file and you get the same shape of output Figma Console MCP produces, DTCG-format tokens ready for Claude, Cursor, or whatever's writing the code, minus the requirement that someone already did the design-ops work in Figma first. The output formats converge; the input doesn't have to. Three ways to get design tokens into an AI coding agent right now, and what each one assumes you already have: - [Figma Console MCP](https://github.com/southleft/figma-console-mcp): Exports Figma variables to DTCG 2025.10, CSS, Tailwind, SCSS, TS and more over MCP, with full bidirectional sync. Requires an existing Figma file with real variables set up. - [Style Dictionary](https://styledictionary.com/): The long-standing open-source token build pipeline this new tool is explicitly positioned to replace. Still needs a source tokens file to transform, from Figma or hand-written. - [WAALEE](https://waalee.ai/): Paste any live URL, no Figma file or token file required, and get real colors, type scale, spacing, and W3C tokens back as AI-ready prompts for Claude, Lovable, v0, Cursor, and Bolt. ## Use the one that matches your source of truth This isn't a knock on Figma Console MCP, shipping a dependency-free export across ten formats with a real round-trip is hard, and teams with a maintained Figma library should use it. The gap is the same one this category keeps leaving in the same place: an export pipeline is only as good as what's already structured on the other end of it. If your brand's actual source of truth is a live URL instead of a Figma file, the fix isn't a better export format, it's reading the page the system was actually built on. --- # The best AI website builders in 2026 (and why they all look the same) > Lovable, Bolt, v0, Framer, Wix, Durable and the rest, grouped by what they're actually for. Plus the one thing none of them do for you: give the site a real look. Source: https://waalee.ai/blog/best-ai-website-builders-2026 Published: 2026-10-05 · 7 min read · By The WAALEE Team Topics: best AI website builder, AI website builder 2026, best AI for building websites, Lovable vs Bolt vs v0, AI website generator, free AI website builder, vibe coding website ## Key points - "AI website builder" now covers three different kinds of tool: no-code site builders, AI app builders, and AI coding tools. - Pick by what you need to own: a hosted page you edit, a codebase you can export, or code in your own repo. - Almost every builder ships the same default look. The fix is giving the AI a real design to follow, not a longer prompt. - Start free, ship one real page, and only then pay for the tool you actually kept using. Ask "what's the best AI for building websites?" and you get a different answer from everyone. That's because the question hides three different jobs. One of the busier threads on it, in [r/vibecoding](https://www.reddit.com/r/vibecoding/comments/1qahfj6/whats_the_best_ai_for_building_websites/), starts with someone building a site for their sim racing group who has tried several AIs and found the results all look much the same. Roundups like [Titan's list of AI website builders](https://titan.email/best-ai-website-builders/) mix hosted page builders with tools that write full code. Both are useful. Neither tells you which kind you need first. ## The three kinds of AI website builder ### 1. No-code AI site builders You describe your business, it generates a hosted site, you edit it in a visual editor. Durable, Hostinger's AI builder, Wix and Jimdo live here, and Framer and Webflow sit at the design-heavy end. Best for a local business, a portfolio or a simple landing page you want live today. The trade-off: the site lives on their platform, and most of them don't hand you code you can take elsewhere. ### 2. AI app builders (vibe coding) You chat, it writes a real React app, you see it running. [Lovable](https://lovable.dev/), [Bolt](https://bolt.new/), [v0](https://v0.app/), [Replit](https://replit.com/) and Base44 are the names that come up most. Best for founders building a product, not just a page: logins, a database, payments. You get actual code, and most of these let you sync it to GitHub or download it. ### 3. AI coding tools [Cursor](https://cursor.com/) and [Claude Code](https://claude.com/product/claude-code) work inside your own codebase. There's no hosted editor and no template gallery. Best when you already have a repo or a developer, and you want full control. Slower to start, nothing to outgrow. *Quick comparison. Plans and prices change often, so check each site before you pay.* | Tool | Type | Best for | You own the code? | Design control | | --- | --- | --- | --- | --- | | Durable | No-code builder | A small business site in minutes | No, hosted | Low | | Wix | No-code builder | A full site with bookings, store and blog | No, hosted | Medium | | Framer | No-code builder | Polished marketing and portfolio sites | No, hosted | High | | Webflow | No-code builder | Designers who want pixel control | Export on paid plans | High | | Lovable | AI app builder | Full apps from a chat, with a backend | Yes, GitHub sync | Medium | | Bolt | AI app builder | Fast prototypes in the browser | Yes, export | Medium | | v0 | AI app builder | React and Next.js UI, deploys to Vercel | Yes | Medium | | Replit | AI app builder | Apps with hosting and a database built in | Yes | Medium | | Cursor / Claude Code | AI coding tool | Working inside your own repo | Yes, it's your repo | Full, if you give it a spec | ## How to choose in five minutes 1. Decide what you're shipping: a page people read, or a product people log into. Pages go to a no-code builder. Products go to an app builder. 2. Decide what you need to own. If you might hire a developer later, pick a tool that gives you the code. 3. Try two tools with the same prompt. Don't read reviews for an hour; spend twenty minutes building. 4. Ship one real page before you pay. The free tier tells you more than any comparison table, this one included. 5. Before you share it, fix the look. That's the part every builder leaves to you. ## Why they all look the same Here's the part most "best AI website builder" lists skip. Every tool above is very good at making a site that works. Almost none of them make a site that looks like yours. Ask for "a modern landing page" and you get the same thing everywhere: the default font, a centered hero, rounded cards and a purple-to-blue gradient. The AI isn't being lazy. You didn't give it a design, so it used its defaults. ## What builders are saying > A sim racing group organiser asks which AI is best for building a website, because the ones they've tried all produce sites that look alike. The thread has 75+ replies comparing tools. > (r/vibecoding: https://www.reddit.com/r/vibecoding/comments/1qahfj6/whats_the_best_ai_for_building_websites/) > "AI-generated websites always look generic. How do you fix this?" The fixes people list: different prompts, layout systems, design tokens and seed-based variations. > (r/SideProject: https://www.reddit.com/r/SideProject/comments/1r5zw5v/aigenerated_websites_always_look_generic_how_do/) > "Most AI-built websites look the same because most people skip the identity work and accept AI's defaults." > (Unpromptable: https://unpromptable.substack.com/p/5-ai-website-design-tips-for-websites) Design tokens come up again and again for a reason. When an AI tool gets your exact colors, fonts, spacing and button styles as a spec, it stops guessing. That works in every tool above, because they all take a prompt. We wrote up [nine fixes for the generic AI look](https://waalee.ai/blog/ai-websites-look-the-same-fixes) if you want the full list. Where WAALEE fits: it isn't a website builder. It's the design step you run before, or after, whichever builder you pick. - [Titan: best AI website builders](https://titan.email/best-ai-website-builders/): A long roundup of hosted AI site builders with a comparison table. Good if you want a no-code site and a domain in one go. - [Lovable](https://lovable.dev/): One of the most used AI app builders. Chat to a working app with a backend, synced to GitHub. - [WAALEE](https://waalee.ai/): Paste a website you like (or your own) and get its real colors, fonts, spacing and components as a ready prompt for Lovable, Bolt, v0, Cursor or Claude. Free to try. ## Frequently asked questions ### What is the best AI website builder in 2026? It depends on the job. For a simple hosted site, a no-code builder like Durable, Wix or Framer is fastest. For a product with logins and a database, an AI app builder like Lovable, Bolt, v0 or Replit. If you already have code, Cursor or Claude Code. ### Is there a free AI website builder? Most of the tools here have a free tier or a free trial. Free tiers usually limit how many messages or credits you get, or put the site on a subdomain. Check each tool's pricing page, because limits change often. ### Lovable vs Bolt vs v0: which should I use? All three turn a chat into a working React app. Lovable leans toward full apps with a backend, Bolt toward fast prototypes in the browser, and v0 toward UI components and Next.js on Vercel. Try the same prompt in two of them and keep the one you like working in. ### Do I own the code an AI website builder makes? With AI app builders and coding tools, yes: you can usually sync to GitHub or download the project. With most no-code builders, the site stays on their platform. Read the terms if ownership matters to you. ### Why does my AI-built website look generic? Because the AI had no design to follow, so it used its defaults: the same font, layout and gradient as everyone else. Give it a real spec (colors, fonts, spacing, components) taken from a site you like, and the output changes a lot. ### Can AI build a website that looks like another site I like? It can follow the same design style, if you give it that style as a spec instead of a description. WAALEE reads a live site and turns its colors, fonts and components into a prompt your builder can follow. Use it for inspiration and your own brand; don't copy someone's logo or content. ### Is vibe coding good enough for a real business website? For a marketing site or an early product, often yes. Have someone check forms, payments and security before you take real customer data, and keep the code somewhere you control. --- # Why every AI website looks the same (and 9 fixes that work) > Same font, same centered hero, same purple gradient. Here's why AI-built sites look generic, and nine practical fixes that work in Lovable, Bolt, v0, Cursor and Claude. Source: https://waalee.ai/blog/ai-websites-look-the-same-fixes Published: 2026-10-05 · 7 min read · By The WAALEE Team Topics: AI website looks generic, make AI website look unique, AI slop design, vibe coded site design, how to make Lovable site look better, design tokens for AI, AI website design tips ## Key points - AI sites look the same because the AI fills every gap you leave with its defaults. - The fix isn't a longer prompt. It's a real design spec: colors, fonts, spacing, components. - Collect references first, then give the AI exact values, not adjectives. - Change three things and most of the "AI look" disappears: the font, the accent color and the hero layout. Open five sites built with AI this month and you'll see one site. Inter, or whatever the default font is that week. A centered headline over a soft purple-to-blue gradient. Three rounded cards with an emoji each. A [r/SideProject thread](https://www.reddit.com/r/SideProject/comments/1r5zw5v/aigenerated_websites_always_look_generic_how_do/) asks the question directly, and [Unpromptable put it plainly](https://unpromptable.substack.com/p/5-ai-website-design-tips-for-websites): "Most AI-built websites look the same because most people skip the identity work and accept AI's defaults." ## Why it happens An AI builder has to decide hundreds of small things: font, size, spacing, corner radius, shadow, color, layout. If your prompt says "make it modern and clean," it decides almost all of them for you, using the safest answer it knows. The safest answer is the most common one. So every site gets the most common design on the internet. - The default font, at every size, for everything. - The component library's stock look: gray borders, rounded-xl cards, untouched spacing. - A purple or blue gradient that has nothing to do with any brand. - A centered hero, three feature cards, a pricing table, a FAQ. Always in that order. - Emoji standing in for real icons. ## 9 fixes that work 1. **Collect references before you prompt.** Save 10 to 15 sites you love from Awwwards, Dribbble, Behance or your competitors. Taste is the input the AI can't invent for you. 2. **Give exact values, not adjectives.** "Background #0b0b0c, text #f5f5f4, accent #ff5a1f, 8px radius" beats "dark and bold" every time. These values are your design tokens. 3. **Pick a real font pairing.** One display font with character and one plain text font. Name them in the prompt and say where each one goes. 4. **Choose one accent color and use it sparingly.** One brand color on buttons and links, neutrals everywhere else. Ban gradients unless your brand actually has one. 5. **Sketch the layout first.** Even a rough drawing of section order on paper stops the AI from defaulting to hero, three cards, pricing. 6. **Start from real components.** Libraries like [21st.dev](https://21st.dev/) and agent skills from [skills.sh](https://skills.sh/) give the AI better building blocks than its stock ones. 7. **Write a design file the AI reads every time.** A DESIGN.md or rules file in your project keeps the look consistent across every new page and every new chat. 8. **Change one thing per prompt.** "Make it better" rewrites everything. "Tighten the hero spacing to 96px top and bottom" fixes one thing and keeps the rest. 9. **Treat the AI as a collaborator, not a vending machine.** Look at what it made, say what's wrong in specific terms, and iterate. Two or three rounds is normal. ## A prompt template you can copy Paste this into Lovable, Bolt, v0, Cursor or Claude and fill in the brackets. The more exact the values, the less the AI guesses. - Style reference: [site you like], match its overall feel, not its content. - Colors: background [hex], surface [hex], text [hex], muted text [hex], accent [hex] (buttons and links only), border [hex]. - Fonts: headings [font, weight], body [font, size, line height]. - Shape: corner radius [px], borders [1px, color], shadows [none / soft]. - Spacing: section padding [px], content max width [px]. - Layout: [your section order]. No gradients, no emoji icons, no centered-everything. *What changes when you give the AI a spec* | | Prompt with adjectives | Prompt with a spec | | --- | --- | --- | | Font | Whatever the default is | The fonts you named | | Colors | Purple-blue gradient | Your palette, one accent | | Buttons | Stock component style | Your radius, padding and color | | Layout | Hero, 3 cards, pricing | Your section order | | Next page | Drifts to a new look | Matches, because the spec is reused | ## What people suggest > Commenters on the r/SideProject thread point to different prompts, layout systems, design tokens and seed-based variations as ways to break the generic look. > (r/SideProject: https://www.reddit.com/r/SideProject/comments/1r5zw5v/aigenerated_websites_always_look_generic_how_do/) > Unpromptable's five tips: develop taste, work with pre-existing assets, build your own assets, sketch before you prompt, and treat AI as a collaborator. > (Unpromptable: https://unpromptable.substack.com/p/5-ai-website-design-tips-for-websites) > People asking which AI is best for websites often find the tool matters less than they hoped: every one they try gives a similar-looking result. > (r/vibecoding: https://www.reddit.com/r/vibecoding/comments/1qahfj6/whats_the_best_ai_for_building_websites/) ## The shortcut: take the spec from a site you already like Fixes 1, 2, 3, 4 and 7 are the slow part: finding the exact hex codes, fonts, spacing and button styles of a site you admire, then writing them up. That's the step WAALEE does for you. Paste a URL, and it reads the live site and gives you its real colors, fonts, spacing and components as a prompt and a DESIGN.md file, ready for whichever builder you use. Use it on your own site to keep new pages on-brand, or on a reference site for inspiration. Then make the content, the logo and the voice your own. Three good places to start fixing a generic AI site: - [Unpromptable: 5 AI website design tips](https://unpromptable.substack.com/p/5-ai-website-design-tips-for-websites): A clear essay on doing the identity work first: taste, references, sketches, and when to hire a designer. - [21st.dev](https://21st.dev/): A large library of community UI components with copy-paste prompts, so the AI starts from better building blocks. - [WAALEE](https://waalee.ai/): Paste any live site and get its real design system (colors, fonts, spacing, components) as a ready prompt for Lovable, Bolt, v0, Cursor or Claude. Free to try. ## Frequently asked questions ### Why do AI-generated websites look generic? Because the AI fills every design decision you don't specify with its most common default. Same defaults, same site. Give it exact colors, fonts, spacing and layout and the output stops looking generic. ### How do I make my Lovable or Bolt site look better? Give it a design spec instead of adjectives: hex colors, named fonts, a corner radius, spacing values and a section order. Keep that spec in a file the tool reads on every prompt, and change one thing at a time. ### What are design tokens, in plain words? They're the exact values that make up a look: colors, font sizes, spacing, corner radius, shadows. Written down as names and values, so a person or an AI can reuse them the same way every time. ### What is "AI slop" design? A nickname for the default look AI tools produce when nobody guides them: the stock font, purple gradients, centered heroes, emoji icons and identical cards. It isn't broken, it's just everyone else's site. ### Do I need a designer to fix an AI-built site? Not always. References, a clear spec and a few rounds of focused prompts get most sites from generic to decent. For a brand identity (logo, voice, a distinctive system), a designer is still worth it. ### Can I copy another website's design with AI? Use other sites for inspiration and style, not as something to clone. Matching a feel (spacing, type scale, color mood) is normal design practice. Copying logos, images, text or a trademarked look is not. --- # Dembrandt, StyleKit, WAALEE: picking a design token extractor > A wave of free tools now pull colors, type and spacing straight off a live site. Here's what actually separates a CLI, a browser extension and WAALEE. Source: https://waalee.ai/blog/design-token-extractors-dembrandt-stylekit-compared Published: 2026-10-03 · 4 min read · By The WAALEE Team Topics: design token extractor, extract design tokens from website, DESIGN.md generator, DTCG design tokens, AI coding agent design system, website design system scraper Eighteen months ago, pulling a design system off a live site meant opening DevTools and doing it by hand. Now there's a small wave of tools that do it in one command or one click: [dembrandt](https://www.npmjs.com/package/dembrandt), an open-source CLI that shipped this year and crossed two thousand GitHub stars fast, and [StyleKit](https://chromewebstore.google.com/detail/jbbngpjghnifmnmlfcjacooakmhhglge), a free Chrome extension doing the same job from a toolbar icon. WAALEE has been in this exact lane since before either existed. Worth being straight about what's actually different now that extraction itself is no longer the hard part. ## What each one reads, and what it hands back Dembrandt is a TypeScript CLI you run against any URL. Per its own docs, it uses Playwright to render the page in a real Chromium (or Firefox) tab, reads the computed styles off the live DOM, then applies heuristics and optional ML to score colors, type, spacing, borders, motion and components by confidence. It outputs to terminal, JSON, W3C DTCG tokens, or a DESIGN.md file, and it exposes `get_design_tokens`, `get_color_palette` and `compute_drift` as MCP tools, so an agent can call it directly instead of reading a file. It also has a drift-detection mode with exit codes, built for a CI pipeline that fails a PR when a site's tokens change unexpectedly. StyleKit is the opposite shape: no install beyond a browser extension, no terminal. Click its icon on any open tab and it reads CSS computed styles in place, colors with hex codes, font families and weights, spacing and margin values, radii, shadows, then exports the lot as a DESIGN.md file. Nothing leaves the browser, no account, no server round trip. That makes it the fastest path from "I'm looking at a site I like" to a file an agent can read, with nothing to set up first. - Dembrandt: CLI + MCP server, DTCG and DESIGN.md output, drift detection for CI, built for a team automating extraction across many sites or watching one for change. - StyleKit: one click in the browser, DESIGN.md only, no account or install beyond the extension, built for a single quick capture while you're already looking at the page. - WAALEE: paste a URL in the browser, get W3C tokens back as ready-to-paste prompts for five specific tools, Claude, Lovable, v0, Cursor and Bolt, not just a token file you still have to introduce to each one yourself. ## Format stopped being the differentiator A year ago, "does it output real tokens or just a vibe" was the whole question. It mostly isn't anymore. Dembrandt and StyleKit both land on DTCG-shaped output or DESIGN.md, the same formats the rest of this space (Google's own [design.md spec](https://github.com/google-labs-code/design.md) included) has converged on. That's a healthy sign for the category: extraction got commoditized, which is good for anyone building on top of it. It also means the actual decision for a founder or small team isn't "which tool reads CSS correctly," it's closer to: do you want a pipeline you run and re-run (dembrandt), a one-off capture with zero setup (StyleKit), or output already shaped for the specific coding tool you're about to open. ## Where the gap still sits Both dembrandt and StyleKit hand you a token file, and from there it's on you to know what Claude wants versus what Lovable wants versus what a Cursor rules file expects, and to translate the same palette into each one correctly. That's a small tax per tool, but it compounds the moment you're moving between four or five of them on the same project, which is the normal state of building anything with AI right now. WAALEE treats that translation as the actual product: one extraction, five AI-ready prompt formats, so the token set that comes out matches what each tool's own prompt conventions expect instead of a generic JSON blob you reformat by hand every time. Three ways to get a live site's real design system out as something an AI tool can use: - [dembrandt](https://www.npmjs.com/package/dembrandt): Open-source CLI and MCP server. Playwright-rendered extraction, DTCG/DESIGN.md output, drift detection for CI. Best for a team automating extraction or gating PRs on token changes. - [StyleKit](https://chromewebstore.google.com/detail/jbbngpjghnifmnmlfcjacooakmhhglge): Free Chrome extension, one click on any open tab, exports DESIGN.md. No install beyond the extension, no account, nothing leaves the browser. - [WAALEE](https://waalee.ai/): Paste a live URL and get real colors, type, spacing and W3C tokens back as AI-ready prompts already shaped for Claude, Lovable, v0, Cursor and Bolt, not one generic file to adapt per tool yourself. None of this is a knock on dembrandt or StyleKit. A free, one-click extractor and an open CLI with CI hooks both make the first step of this problem genuinely easier, and more tools reading real computed styles instead of guessing is good for everyone building AI-assisted sites. The thing worth checking before you pick one is what you actually do with the output five minutes later: write a config file by hand for each tool you use, or open a prompt that's already correct for it. --- # ux-skill kills AI slop with 152 rules. It still isn't your brand > ux-skill's deterministic linter and 160 brand specs stop AI coding agents from shipping generic UI. The specs come from Apple, Linear and Stripe, not from your own site. Source: https://waalee.ai/blog/ux-skill-anti-ai-slop-linter-your-brand-gap Published: 2026-10-01 · 4 min read · By The WAALEE Team Topics: ux-skill MCP server, anti-AI-slop linter, AI coding agent brand consistency, design tokens for AI agents, extract design system from website, stop AI generated website looking generic [ux-skill](https://github.com/Laith0003/ux-skill) is an open-source design intelligence engine that plugs into Claude Code, Cursor and Windsurf. Its pitch is blunt and correct: coding agents optimize for "does it run," so they default to the same safe layout, the same gray-on-white Tailwind palette, the same rounded card with a purple gradient. ux-skill ships a 152-rule deterministic linter that catches that pattern before it ships, no LLM call needed, plus a synthesizer that recommends a full design system from a brief. It's a genuinely useful piece of infrastructure. It also answers a different question than the one most teams actually have. ## What the linter actually catches Per the project's own docs, the `ux_lint` tool runs 152 regex-based rules against your files and returns findings with a rule id, severity, file, line, excerpt and fix, entirely offline. That's the right way to enforce "don't do this": no model in the loop to talk itself out of a rule, no drift between runs. It's the same instinct behind a linter for code style, just aimed at the visual output an agent produces instead of the syntax it writes. - The default shadcn look: rounded-xl cards, the same two grays, zero visual identity. - Inter (or the current default font) used everywhere, at every weight, for every purpose. - A purple-to-blue gradient hero with no connection to any actual brand. - Emoji used as section icons instead of real iconography. - Spacing and radii that are whatever the component library shipped with, untouched. ## Where the brand it recommends comes from The part worth reading closely is the synthesizer. ux-skill's v3.0 update, [documented on its own blog](https://uxskill.laithjunaidy.com/blog/brand-specs-training-data-not-templates.html), reframed its 160 brand specs: they used to be a catalogue the tool picked from, now they're described as "vocabulary" that a 7-axis engine distills into a fresh system per brief. Those 160 specs are real design data pulled from Apple, Linear, Vercel, Stripe, Ferrari, Anthropic and other well-known brands. Give the engine an industry, audience and tone, and it returns a palette, type pairing, motion presets and components, deterministically, same brief in, same system out. That's a strong answer if you're starting from nothing and need a plausible design language fast. It's a different answer if you already have a brand. The project's own changelog treats an existing design system as "fixed input," meaning ux-skill will respect it once you hand it over, but the handing-over is still on you: someone has to transcribe your actual palette, type scale and spacing into whatever format the tool expects. Nothing in ux-skill looks at your live site and pulls that out for you. ## A linter is not a source of truth This is the same shape of gap as the Figma-pipe tools and CSS inspectors this space keeps shipping: a real improvement at enforcing or reading design decisions, built on the assumption that the decisions themselves are already captured somewhere clean. For a team with no existing brand, synthesizing one from Apple and Stripe's vocabulary beats shipping the Tailwind default. For a team that already has a shipped site with a real identity, that's not the problem, the problem is getting that identity into every agent's hands as structured input instead of a paragraph of adjectives someone writes from memory. That's the step WAALEE handles. Paste a live URL and it extracts the actual colors, type scale, spacing and radii as W3C design tokens, ready to paste into Claude, Cursor, Lovable, v0 or Bolt, or to hand to a linter like ux-skill as the "fixed input" it's already built to respect. Your agent stops guessing at a brand and stops borrowing one from Stripe's playbook. It builds from yours. Three ways to keep an AI coding agent from drifting into generic output, and what each one assumes you already have: - [ux-skill](https://github.com/Laith0003/ux-skill): 152-rule offline linter plus an MCP server that blocks AI-slop patterns in Claude Code, Cursor and Windsurf. Strong at catching generic output; recommends a system synthesized from 160 other brands' specs, not yours. - [ux-skill: Brand specs as training data](https://uxskill.laithjunaidy.com/blog/brand-specs-training-data-not-templates.html): The project's own v3.0 writeup: its 160 brand specs are vocabulary for a synthesizer, and an existing design system is handled as fixed input you supply yourself. - [WAALEE](https://waalee.ai/): Paste any live URL and get your actual colors, type, spacing and W3C tokens back as AI-ready prompts, the fixed input a linter or coding agent needs to build from your real brand instead of a borrowed one. Rules stop the worst output. They don't tell an agent what your brand actually looks like. If you already have one, feed it in directly instead of describing it from memory. --- # OpenAI dots: always-on AI agents are here. Your brand isn't in them > OpenAI's new dots agents take on ongoing work, from proposals to working demos. Here's how fast agents are evolving, and why your design system has to be machine-readable now. Source: https://waalee.ai/blog/openai-dots-always-on-ai-agents-brand Published: 2026-09-30 · 5 min read · By Kiana Bluecher and The WAALEE Team Topics: OpenAI dots agent, OpenAI DevDay 2026, always-on AI agents, AI agents brand consistency, design tokens for AI agents, ChatGPT Sites design system At DevDay 2026 on September 29, OpenAI introduced [dots](https://openai.com/index/introducing-dots/), which it calls remarkably capable, always-on agents. Not a chatbot you open when you have a question, but an agent that keeps working on your behalf, learns what matters to you, and takes ongoing responsibilities off your plate. It is the clearest signal yet of where AI is heading: from answering prompts to owning work. And the more work agents own, the more of your brand they will produce without a designer in the loop. ## What OpenAI actually launched According to [OpenAI's DevDay recap](https://openai.com/index/devday-2026-recap/) and [reporting from the event](https://www.the-independent.com/tech/dots-openai-launch-live-demo-b3058720.html), dots run on their own cloud computers and on GPT-6 Astra. They can manage projects as they change, for example updating a sales proposal when a customer's needs shift and building a working demo for review. You talk to them in Slack and Teams, and they draw on Codex and ChatGPT Work to research, analyze data, prepare documents and build software. Dots are available on Pro and Business Premium in eligible markets, with an admin-enabled beta for Enterprise. Dots were not the only agent news. The same keynote added computer use to the Agents API, MCP events so plugins can trigger automations when something happens in a connected app, Sites that can host plugins, ChatGPT Space and Pages for humans and agents working in the same document, and collaborative slides that export to PowerPoint and Google Slides. OpenAI also said users can set rules for what dots may do and when to ask permission, a response to real safety concerns: the live demo was glitchy, and the day before, the company held back a more powerful model over how it behaved. ## How fast this is moving Two years ago the pattern was: you prompt, the model answers, you copy the result somewhere. Last year it became: you connect tools over MCP and the model acts inside them. Now it is: an agent holds a standing responsibility and does the work while you are away. Meta's personal agent Muse drew millions of downloads earlier this month, and [OpenAI positioned dots directly against it](https://www.sun-sentinel.com/2026/09/29/openai-new-agent-dot/). OpenAI says Codex and ChatGPT Work now have more than 35 million weekly users, up from about 5 million Codex users in June. - 2024: chat. You describe what you want, then paste the output into your tools yourself. - 2025: connected. MCP lets Claude, ChatGPT and Cursor read and write inside your apps. - 2026: always-on. Agents like dots own recurring work, react to events and ship drafts, demos, pages and decks on their own schedule. ## The part nobody demos: what the output looks like Every capability above ends in something a customer sees. A proposal, a demo app, a Site, a slide deck, a landing page. When a person builds those, they open the brand guide. When an agent builds them overnight, it uses whatever style it can find, and if it finds nothing it falls back to its defaults. That is how vibe-coded apps ended up with the same purple gradient and the same rounded cards. Multiply that by an agent that ships work every day and brand drift stops being a design problem and becomes an operations problem. The fix is not a longer prompt that says "make it on brand". Agents do not follow adjectives, they follow values. They need your real colors, type scale, spacing and radii as structured data they can read on every run: W3C design tokens, CSS variables, and a short set of rules for how to use them. ## Give your agents a design system they can read This is what WAALEE is built for. Paste your live site or a reference you love, and WAALEE extracts the real design system and turns it into tokens and prompts an agent can use. Connect the WAALEE MCP server in ChatGPT or Claude and any agent can pull that system on demand, so the proposal, the demo and the deck your agent builds tonight come out looking like your company instead of a template. Where agents are today, and what each one needs from you to stay on brand: - [OpenAI dots](https://openai.com/index/introducing-dots/): Always-on agents that own ongoing work in Slack and Teams, powered by GPT-6 Astra, Codex and ChatGPT Work. They build documents, demos and software, so they need your brand rules as data, not a PDF. - [OpenAI Agents API](https://openai.com/index/devday-2026-recap/): Now with computer use, multi-agent support and tool search for teams building their own agents. The same rule applies: whatever design context you pass in is what comes out. - [WAALEE](https://waalee.ai/): Extracts a site's real colors, type, spacing and W3C tokens from any URL and serves them over MCP, so ChatGPT, Claude and Cursor agents build from your system instead of their defaults. Agents are getting more capable every month. The companies that stand out will be the ones whose agents already know what the brand looks like. Start with one URL: [extract your design system on WAALEE](https://waalee.ai/) and connect it to the agents you already use. --- # Anima MCP connects your AI agent to Figma. It still needs a system > Anima's new MCP server pipes Figma components and tokens straight to Claude Code and Cursor. It only helps if a real design system already exists in Figma. Source: https://waalee.ai/blog/anima-mcp-figma-design-system-gap Published: 2026-09-29 · 4 min read · By The WAALEE Team Topics: Anima MCP server, Figma to code AI agent, design system MCP Figma, AI coding agent design tokens, Claude Code Figma integration, extract design system without Figma [Anima](https://animaapp.com/) shipped its own MCP server this year, a hosted endpoint that connects Claude Code, Cursor, or any MCP-compatible agent straight to Anima Playground and a linked Figma file. The pitch is the same one this whole category keeps making: stop pasting screenshots into a prompt, let the agent read the real file. It's a genuine improvement over screenshot-and-hope. It also runs on the same assumption every Figma-to-code tool has run on for two years, that the design system you're building from already exists, in Figma, in a shape worth reading. ## What Anima MCP actually hands an agent Per [Anima's own writeup](https://animaapp.com/blog/code/connect-your-ai-coding-agent-to-anima-playground-and-figma-with-mcp/), the server exposes file structure, component relationships, and design-system assets to a connected agent, so it can implement a screen the way someone who actually understands the project would, matching existing patterns instead of guessing them. For a team that's handed off an Anima project or a specific Figma feature to an agent, that's a real step up from a static export. The agent sees the component tree, not a flattened PNG. ## The part that only works if Figma already has the answer Every capability in that pitch is downstream of one condition: a Figma file with a real, current design system already sitting in it, components, variables, a library someone maintains. That's true of Anima MCP the same way it was true of [Figma's own Dev Mode MCP server](https://www.figma.com/blog/introducing-figma-mcp-server/) when it shipped last year. Neither tool can navigate to a URL and pull a system out of thin air. Both need a node-id, a file, and permission to open it. If your brand's real design decisions live in a shipped website instead of a maintained Figma library, which is most companies past their first six months, there's nothing here to connect to. - A founder who's never opened Figma but has a live site that already looks right. - An agency picking up a client whose old design file is gone, outdated, or was never made, the site was built straight in code. - A team benchmarking a competitor's site, where no one is ever handing over the Figma file. - Anyone rebuilding a reference site they admire rather than one they have edit access to. ## Read the rendered page instead of the source file None of those situations are dead ends, they just need to start from a different source of truth. A live site is the same design system rendered, fonts resolved, colors computed, spacing laid out, just without the Figma layer names attached. Point a tool at the URL instead of the file, pull the real computed palette, type scale, spacing, and radii, and you get back the same kind of structured input an agent needs, W3C-format tokens instead of a component tree, ready to hand to Claude, Cursor, or whatever built the Anima project in the first place. Three ways a coding agent gets design context right now, and what each one requires you to already have: - [Anima MCP](https://animaapp.com/blog/code/connect-your-ai-coding-agent-to-anima-playground-and-figma-with-mcp/): Hands an agent file structure, components, and design-system assets from a connected Anima Playground project and Figma file. Requires an existing Anima project and access to the Figma file behind it. - [Figma Dev Mode MCP](https://www.figma.com/blog/introducing-figma-mcp-server/): Same underlying constraint from Figma itself: variables and component data, but only for files you can already open, and only past a certain seat tier. - [WAALEE](https://waalee.ai/): Paste any live URL, no Figma file or Anima project required, and get real colors, type scale, spacing, and W3C tokens back as AI-ready prompts for Claude, Lovable, v0, Cursor, and Bolt. ## Use each one for the system it can actually see None of this is a knock on what Anima built. A hosted MCP endpoint that gives an agent real component relationships instead of a screenshot is a solid piece of infrastructure, and it'll save real time for teams whose system already lives where it expects to look. The gap is the one this category keeps leaving in the same place: a pipe to Figma is only as useful as what's already in Figma. If your brand's actual source of truth is a live URL instead, the fix isn't a better MCP server, it's reading the page the system was built for in the first place. --- # Chrome DevTools MCP gives agents real CSS. Not a design system > Google's Chrome DevTools MCP now hands Claude Code and Cursor an element's exact CSS cascade. It answers one element at a time, not what a whole site's palette is. Source: https://waalee.ai/blog/chrome-devtools-mcp-css-styles-design-system-gap Published: 2026-09-27 · 4 min read · By The WAALEE Team Topics: Chrome DevTools MCP, get_css_styles tool, MCP server design tokens, AI coding agent CSS inspection, extract design system from live site, vibe coding brand consistency Chrome DevTools MCP hit its 1.0 stable release in May 2026, [Google's own MCP server](https://developer.chrome.com/blog/chrome-devtools-mcp) that hands Claude Code, Cursor, Antigravity, and Copilot direct control of a live Chrome tab: navigating, clicking, profiling, and, per a documentation update that landed this month, reading an element's exact CSS. That last part is worth pausing on, because it's tempting to read "an agent can now inspect real CSS on any page" as "an agent can now extract a design system from any page." It can't, and the gap between those two claims is worth being precise about. ## What get_css_styles actually returns The new tool, [documented in the project's tool reference](https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/tool-reference.md), takes a `uid` from a prior `take_snapshot` call and returns the full cascade behind that one element: matched CSS rules, inline styles, inherited styles, custom properties, and any `@layer`, `@media`, `@container`, or `@scope` wrappers, ordered from highest to lowest precedence, with overridden declarations tagged `[overloaded]`. That's a meaningfully better answer than the workaround agents used before, calling `evaluate_script` to run `getComputedStyle` by hand, because it shows the whole cascade an agent can reason about, not just the single resolved value a script would return. The project's own skill docs now tell agents to prefer it over scripting a computed-styles read themselves. ## One element, one call, every time Here's the boundary. Every call is scoped to one `uid` from one snapshot. Ask what a specific button's color resolves to and which rule is winning, and the answer is precise and complete. Ask "what's this site's actual color palette" and there's no tool for that question, an agent would have to snapshot the whole page, call `get_css_styles` once per element it cares about, and then write its own logic to de-duplicate the resulting hex values into a palette, decide which one is the accent, and work out where a type scale actually steps. That aggregation logic doesn't ship with the server, because Chrome DevTools MCP is a debugging tool that got precise enough to be tempting to misuse as an extraction tool, not the other way around. - get_css_styles answers "why is this element this color," with the full cascade and source line numbers, not "what are this site's colors." - There's no built-in step that walks every element on a page and rolls the results into a palette, a type scale, or a spacing rhythm. - Two agents, or the same agent an hour apart, can produce a different "extracted palette" from the same site, since the aggregation is improvised fresh each time. - It's a genuine upgrade for fixing one wrong shade mid-build. It was never built to answer the question you'd ask before the build starts. ## Other tools already do the aggregation The part Chrome DevTools MCP leaves undone is the actual product of a handful of other tools built for exactly that job. [MiroMiro](https://miromiro.app/), a browser extension and MCP server, walks a live page and hands back a brand kit, colors, fonts, and design tokens, plus paste-ready component code, rather than a per-element cascade dump. It plugs into the same clients, Claude, Cursor, Windsurf, Codex, as a connector, so an agent gets a finished palette in one call instead of assembling one from dozens of `get_css_styles` results. Either approach still leaves the question of exact W3C-format tokens, ready for a codebase rather than a chat window, as a separate step. ## Use each tool for the question it actually answers The two aren't competitors, they sit at different points in the same build. Pull the real palette, type scale, and spacing once, before an agent writes the first line, so the first draft starts from your brand instead of a coding agent's defaults. Then reach for Chrome DevTools MCP's `get_css_styles` mid-build, when one specific card or button isn't rendering the shade it should and you need the exact winning rule, not another pass over the whole system. Asking a debugging tool to do an extractor's job just means writing the aggregation logic yourself, badly, under deadline. Three tools that touch a live page's CSS, and what each one actually hands back: - [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp): get_css_styles returns the full cascade for one element, per call, with source lines and overridden rules marked. No built-in way to aggregate that into a palette or token set. - [MiroMiro](https://miromiro.app/): Browser extension and MCP server that extracts a brand kit, colors, fonts, and component code from a live page in one pass. Closer to a finished palette, not a per-element debug view. - [WAALEE](https://waalee.ai/): Paste a live URL and get the real colors, type scale, spacing, and radii back as exact W3C tokens plus AI-ready prompts for Claude, Lovable, v0, Cursor, and Bolt, no agent session or snapshot loop required. None of this is a knock on what Google shipped. A tool that hands an agent the real, winning CSS rule behind any element, instead of a guess from `evaluate_script`, is a genuine debugging upgrade, and it's the right instinct to expose the actual cascade rather than a flattened value. The gap is just the one this space keeps drawing in the same place: reading CSS precisely and reading a whole design system are different jobs, and a tool built for the first one doesn't quietly become the second just because it got good at what it does. --- # Claude Design's web capture reads your site. Not its exact tokens > Anthropic's Claude Design can now pull colors and fonts straight from a live URL. Read the docs closely and it's extracting your brand's feel, not its exact values. Source: https://waalee.ai/blog/claude-design-web-capture-exact-tokens-gap Published: 2026-09-25 · 4 min read · By The WAALEE Team Topics: Claude Design web capture, Anthropic Claude Design design system, Claude Design exact tokens, extract design tokens from URL, AI design tool brand extraction, vibe coding brand consistency Anthropic's own design tool picked up a feature the rest of this space has been circling all year: point it at a live URL and it pulls your colors, fonts, buttons, and cards straight off the page. [Claude Design](https://www.anthropic.com/news/claude-design-anthropic-labs), the Anthropic Labs product at claude.ai/design, added a web capture method for exactly this, and it's fast, about three minutes for a single domain, per its own docs. Read the support article closely, though, and Anthropic is upfront about what that capture is actually for, and it's not what most teams assume when they hear "extracts your colors." ## What web capture actually does Per [Claude's help center](https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design), a design system in Claude Design can start from chat (pointing at connected apps, uploaded files, Figma files, decks, logos, and fonts), from Claude Code via a `/design-sync` command that reads tokens straight out of a React codebase, or from web capture, pasting a live URL so Claude can grab elements directly from the rendered page. That third path is the one built for a team whose brand only lives on a shipped site, not in a component library or a Figma file anyone kept current. ## "Your brand's feel," not your brand's numbers One line in Anthropic's own documentation says exactly where the ceiling is: a finished landing page or marketing site tells Claude more about your brand's feel than a color palette alone. That's a deliberate framing, not a slip. Web capture is built to give Claude visual context, the vibe, the layout patterns, the general palette, so a new prototype reads as recognizably yours. It's not built to hand back an exact hex code, a precise type scale, or a spacing value you could paste into a Tailwind config with confidence. The docs' own advice for getting it right is to include "real examples, not just specs," and to keep iterating if the first extraction doesn't quite land. That's the language of an approximation you refine, not a measurement you trust on the first pass. ## A browser extension closes part of the gap, for some sites - Claude Design's own web capture reads a URL for visual context: colors, fonts, and components as Claude interprets them, tuned for a coherent-looking prototype, not an exact source of truth. - The `/design-sync` path from Claude Code gets real tokens, but only for teams whose design system already lives in a coded React component library. - WebGrabber for Claude Design, a third-party Chrome extension, captures resolved CSS custom properties per element, real design tokens, when a site is already built with CSS variables. Most marketing sites, Webflow, Wix, WordPress, a decade-old custom build, aren't. - None of the three has a step that turns an ordinary site's plain hex-coded CSS into a token file automatically, before you're already inside an agent session. ### Why this matters more for Claude Design specifically Anthropic built the feature that makes the gap visible faster than most competitors, because it's the first major tool to admit, in its own docs, that a URL capture is a feel-extraction, not a values-extraction. Every other AI design tool this year has quietly let "we read your site" imply "we got your exact brand" and left teams to discover the difference later, usually in a design review. Claude Design just said it plainly, which makes it easier to know when you need something more precise, and when the vibe is genuinely enough. ## Bring the exact values yourself If a prototype needs to match production, not just resemble it, the fix is the same one that applies everywhere in this pipeline: extract the real computed colors, type scale, spacing, and radii off your live site first, as exact values, then feed those into Claude Design as one more upload, a palette and font spec alongside the web capture, instead of asking the capture alone to carry that weight. The vibe extraction still does its job, giving Claude visual context for layout and composition, while the exact numbers come from a source built to measure them, not approximate them. Three ways a live URL turns into design-system material right now: - [Claude Design web capture](https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design): Paste a URL, get colors, fonts, and components as visual context in about three minutes. Anthropic's own docs frame it as capturing your brand's feel, not exact values. - [WebGrabber for Claude Design](https://chromewebstore.google.com/detail/webgrabber-for-claude-des/cmadhofpfmppekfaogbgdppigfipeche): Chrome extension that captures resolved CSS custom properties per element for Claude Design. Real tokens, but only on sites already built with CSS variables. - [WAALEE](https://waalee.ai/): Paste a live URL and get the real colors, type scale, spacing, and radii back as exact W3C tokens, no CSS-variable requirement, ready to upload into Claude Design alongside its own web capture. None of this is a knock on what Anthropic shipped. A three-minute capture that gives a prototype the right visual feel is a genuine convenience, and being explicit that it's feel over precision is more honest than the alternative. The gap is just the one this whole space keeps leaving in the same place: reading a live site for inspiration and reading it for exact values are two different jobs, and right now, most tools, Claude Design included, are still only doing the first one automatically. --- # Figma's Code to Canvas sends your UI to Figma, not your real brand > Figma and Anthropic's Code to Canvas turns a running Claude Code build into editable Figma layers. It still assumes that build's colors and type were already yours. Source: https://waalee.ai/blog/figma-code-to-canvas-claude-code-brand-tokens-gap Published: 2026-09-23 · 4 min read · By The WAALEE Team Topics: Figma Code to Canvas, Claude Code to Figma integration, Figma MCP server design tokens, AI coding agent Figma sync, design tokens for AI coding agents, vibe coding brand consistency Figma and Anthropic shipped something genuinely new this year: [Code to Canvas](https://www.figma.com/blog/introducing-claude-code-to-figma/), announced February 17, 2026, which takes a real, running UI built in Claude Code and pushes it into Figma as fully editable layers and frames, not a flattened screenshot. Every other design-to-code story this year has run in one direction, Figma to code. This one runs backward, and it's the more interesting half. Read past the demo, though, and it still assumes the thing everyone else assumes: that the code you're sending to Figma already has your real brand baked into it. ## What Code to Canvas actually moves The mechanism is straightforward once the Figma MCP server is installed: point Claude Code at a localhost, staging, or production URL, tell it to send the current state to Figma, and the rendered browser output, colors, type, spacing, auto layout, component structure, comes back as native Figma objects you can select, nudge, and restyle like anything drawn by hand. It can even capture a multi-screen flow in one session, preserving the sequence so a reviewer sees the whole path instead of one static frame. For a team whose designers were stuck reviewing code in a browser tab because nothing coded ever made it cleanly back into the file, that's a real fix, not a demo trick. ## It reads what's already rendered. It doesn't check what should be Here's the part worth sitting with. Code to Canvas converts whatever colors, fonts, and spacing are already sitting in the running UI. It has no step that asks whether those values are your brand's actual values or a coding agent's best guess at them. If Claude Code built that UI from a vague prompt and defaulted to its own palette, indigo-on-white, Inter, 8px radii, Code to Canvas will faithfully turn that guess into pixel-perfect, editable Figma layers. You end up with a beautifully organized Figma file of the wrong colors. The tool's own docs are candid about the boundary: alignment with a full design system still has to be done manually, and it does not automatically map new layers to your existing Figma components. ## Other tools point the gap out from a different angle [Superdesign](https://superdesign.dev/blog/extract-design-system-from-website), a design skill built for Claude Code and Cursor, actually ships a command that reads a live URL directly: `superdesign extract-website --url`, which pulls a style guide, tokens, and brand assets off a real site and writes them to a design-system.md file the agent then builds from. That's closer to solving the actual first-mile problem, values in before code gets written, but it's still gated behind installing the CLI, signing into it, and running it inside an agent session before any of it works. Neither tool has a step where someone without an agent open yet can just check what a brand's real hex codes are. - Code to Canvas converts whatever is already rendered, correct brand values or Claude Code's own defaults, with no step that tells the two apart. - Its own documentation says design-system alignment and component mapping are still manual work after the layers land. - Superdesign's extract-website command does read a live URL for real tokens, but only once its CLI is installed and running inside an agent. - In both cases, the fix has to happen before code gets written, not after it's already been pushed to a canvas. ## Get the values right before the first prompt The fix is the same one that applies upstream of every tool in this pipeline: pull the real computed colors, type scale, and spacing off the live page where your brand actually renders before you ever type the first Claude Code prompt. Hand the agent exact hex codes and a real type ramp instead of a description, and the UI it builds starts on-brand, which means whatever Code to Canvas sends back to Figma is on-brand too, no manual realignment required after the fact. Three points in the same pipeline, and where the real brand values have to enter it: - [Figma Code to Canvas](https://www.figma.com/blog/introducing-claude-code-to-figma/): Pushes a running Claude Code UI into Figma as editable layers, preserving structure and flow. Converts whatever colors and type are already in the code, correct or not, and needs manual work to align with existing components. - [Superdesign extract-website](https://superdesign.dev/blog/extract-design-system-from-website): A CLI command that reads a live URL and writes real tokens to a design-system.md file an agent can build from. Solves the sourcing problem, but only once its CLI is installed and signed in. - [WAALEE](https://waalee.ai/): Paste a live URL in the browser, no install, no CLI, no agent session required. Returns the real colors, type scale, and spacing as exact values, ready to open Claude Code's first prompt correctly instead of fixing it in Figma after. None of this is a knock on what Figma and Anthropic built. A clean, structured round trip from running code back into an editable design file is a real, missing piece, and being upfront that component mapping is still manual is more honest than pretending otherwise. The gap is just positioned exactly where it's been all year: these tools move a design system faithfully in whichever direction they're pointed. Making sure what they're moving is actually your brand, and not a plausible guess at it, is still the step that happens before any of this runs. --- # Webflow's new Assets agent needs your brand variables already set > Webflow's Assets, built on its Vidoso acquisition, generates on-brand creative by reading your design system and brand variables. If those don't exist yet, there's nothing for it to read. Source: https://waalee.ai/blog/webflow-assets-vidoso-brand-variables-gap Published: 2026-09-21 · 4 min read · By The WAALEE Team Topics: Webflow Assets Vidoso, Webflow brand variables, AI branded creative generation, Webflow design system tokens, agentic asset generation, vibe coding brand consistency Webflow Conf 2026 wrapped up in Boston earlier this month with a stack of announcements, but the one worth reading past the headline is [Assets](https://webflow.com/blog/webflow-conf-2026-announcements), a new agentic way to produce and adapt branded creative, built on technology from [Vidoso](https://webflow.com/blog/webflow-acquires-vidoso), the AI asset-generation startup Webflow acquired back in March. The pitch is that an agent can now cut a full video down for social, trim filler words, add captions, and resize a static asset across channels, all while staying on-brand automatically. Read the actual requirements and it's the same shape as every other AI branding feature this year: it works once your brand is already defined somewhere machine-readable. It doesn't define it for you. ## What Assets actually needs before it runs Webflow is specific about this, more specific than most vendors bother to be. Per its own announcement, to solve the problem of AI-generated content lacking context, the Assets agents need your design system, your brand variables, your existing asset library, and how those assets have performed. That's four separate inputs, and every one of them assumes a team already did the work of setting up Webflow's Shared Libraries, defining brand variables as actual variables (not just colors picked ad hoc on each page), and building up a library of assets Webflow considers approved. Skip any one of those and there's no context for the agent to read. ## It finds and adapts. It doesn't originate. The mechanism itself is genuinely useful: the agents find, understand, and adapt your approved assets to work across channels, so a hero image built for the homepage can get reflowed for a social crop, or a long-form video can get cut into captioned clips, without a designer touching either by hand. That's real leverage for a marketing team that already has a defined brand living inside Webflow. It's leverage on distribution, not creation. If your actual brand only exists on a live site nobody ever wired into [Shared Libraries](https://webflow.com/feature/shared-libraries) as variables, Assets has no approved library to search and no brand variables to check adaptations against. ## Beta timing means this gap matters now, not eventually Assets enters beta this October, which is close enough that teams evaluating it should know what they're walking into. This isn't a hypothetical six-months-out roadmap item where there's time to casually get around to setting up brand variables. If a team wants to actually test Assets when the beta opens and their site was built years ago, by an agency, with hex codes typed into a color picker one page at a time, the setup work (turning that live rendering into real Webflow variables and an approved library) is the thing standing between them and a useful first session. - Assets reads your design system, brand variables, existing asset library, and past performance data, four inputs that have to already exist inside Webflow. - The agent adapts and distributes approved creative across channels. It has no step for deciding what your brand's real colors and type are in the first place. - It's built on Vidoso, an asset-generation engine, not a brand-extraction one, so it optimizes creative once brand context is supplied, it doesn't supply that context. - Beta opens this October, which makes getting real brand variables into Webflow now, not later, the actual prerequisite for testing it well. ## Get the variables in before the beta opens The fastest way to have Webflow's design system and brand variables actually match your real brand, rather than a rough guess typed in from memory, is to pull the values off the page where your brand already renders: your live site, whatever it's built in. Read the real computed colors, the actual type scale, the true spacing rhythm off the rendered DOM, and you can wire those straight into Webflow's variables and Shared Libraries as exact values instead of an approximation. That turns the four inputs Assets is waiting for from a blocker into a checklist you clear in one sitting. Three pieces of the same pipeline, and where the brand values actually have to start: - [Webflow Assets](https://webflow.com/blog/webflow-conf-2026-announcements): Finds, adapts, and distributes approved creative across channels once your design system, brand variables, and asset library already exist. Beta opens October 2026. - [Webflow Shared Libraries](https://webflow.com/feature/shared-libraries): Where those brand variables, components, and assets actually have to live for Assets (or anything else in Webflow) to read them. Setup is manual, page by page, unless the values are already exact. - [WAALEE](https://waalee.ai/): Paste a live URL and get the real colors, type scale, and spacing back as exact values in seconds, ready to enter into Webflow's brand variables instead of guessing them from memory before the Assets beta opens. None of this is a knock on what Webflow built. An agent that can adapt approved creative across a dozen channels without a designer manually resizing each one is a real, compounding time save, and being explicit about the four inputs it needs is more honest than most "just describe your brand" pitches in this space. The gap is the same one every agentic branding feature this year keeps leaving in the same place: it's good at working with a brand once one is defined. Defining it, precisely, is still the step that happens before any of this runs. --- # Bolt.new's Design System Agents assume you already have one > Bolt.new and Replit both shipped agents that reuse an existing design system faithfully. Neither one extracts tokens from a live site that never had one. Source: https://waalee.ai/blog/bolt-replit-design-system-agents-source-gap Published: 2026-09-19 · 4 min read · By The WAALEE Team Topics: Bolt.new Design System Agents, Replit Figma Design System import, AI coding agent design tokens, bring your own design system AI, design system source of truth, vibe coding brand consistency Two more platforms shipped a "make the agent build on your design system, not its own" feature this cycle: [Bolt.new's Design System Agents](https://bolt.new/blog/bolt-design-system-agents) and [Replit's Bring Your Own Design System import](https://replit.com/blog/introducing-comprehensive-design-support-for-ai-apps). Read past the announcement copy and both make the same assumption Lovable, Webflow, and v0 already made earlier this year: a clean design system to feed the agent already exists somewhere. Neither one goes and gets it off a site that's live today but was never turned into a token file. ## What Bolt.new's Design System Agents actually ingest Per Bolt's own announcement, Design System Agents ingest source files that define your company's visual identity: UI components straight from your codebase, npm packages, Storybook sites, documented component specs, logos, iconography, proprietary fonts, and brand guidelines. Once it has those, the agent builds with "the exact same bin of pre-molded Lego bricks" your engineering team already uses, instead of inventing a plausible-looking button or card from training data. That's a real fix for a real cost Bolt calls the "translation tax": the weeks engineers spend rebuilding an AI prototype to match production before it can actually ship. ## The catch: it assumes the bin of bricks already exists Notice what's on that source list. A coded component library, a live Storybook, a written brand guideline doc, real font files, an actual npm package. Every one of those is something a team has to have already organized and exported. If your "design system" is really just a live marketing site nobody ever componentized, or a Webflow or Squarespace build with hex codes typed into the color picker one page at a time, there's no bin of bricks yet to hand the agent. Bolt's agent is genuinely good at reusing a system that exists. It has no feature for authoring one it was never given. ## Replit's version has the same shape, plus two more gates Replit shipped something structurally similar on nearly the same beat: [Bring Your Own Design System](https://replit.com/blog/introducing-comprehensive-design-support-for-ai-apps), which lets you import a design system from Figma, or upload a package containing your design tokens and rules, and apply it to new Agent-built apps. Two details in the announcement are worth reading closely. First, it's explicitly "Beta for Enterprise Customers" only. Second, quoted directly: "This release supports all new apps built with Replit, with support for previously built apps on the way." So even inside Replit, an app you already built can't retroactively adopt the imported system yet. And outside Replit, a live site's real colors and type still have to be extracted and turned into a Figma file or token package before the import step even starts. - Bolt's Design System Agents need your components, brand guidelines, and fonts already assembled as source files, not read off a live URL. - Replit's import needs a Figma file with real variables, or a token package already built, and it's gated to Enterprise beta, new apps only. - Neither one has a "paste a URL" step, because neither one is trying to answer where the tokens come from in the first place. - Both fixes are aimed downstream of that question: building faithfully once a system exists, not producing the system itself. ## The step before either agent can help None of this is a gap in the engineering. Reusing real components instead of guessing at new ones is a genuine, overdue fix, and two serious platforms shipping it within weeks of each other says something about where the actual bottleneck moved this year. It moved to sourcing. If your brand's real colors, type, and spacing only live on a rendered page today, built years ago, by an agency, in a stack neither importer reads, someone still has to go get those values before "bring your own design system" means anything. The fastest way there is the same move for either platform: extract the computed colors, type scale, spacing, and radius straight off the live page where your brand actually renders, then hand the resulting token file to Bolt as one more brand-guideline source, or upload it as the token package Replit's importer is waiting for. That turns "bring your own" from a requirement you can't meet into a five-minute step. Two agents built to reuse a design system faithfully, and where the tokens have to come from first: - [Bolt.new Design System Agents](https://bolt.new/blog/bolt-design-system-agents): Reads your components, npm packages, Storybook, brand guidelines, and fonts once they're organized as source files. No step that reads a live, un-componentized site. - [Replit: Bring Your Own Design System](https://replit.com/blog/introducing-comprehensive-design-support-for-ai-apps): Imports from Figma or an uploaded token package, Enterprise beta, new apps only. Assumes the Figma file or package already has real values in it. - [WAALEE](https://waalee.ai/): Paste a live URL and get the real colors, type scale, spacing, and radius back as W3C tokens in seconds, ready to feed either agent as the source file it's waiting for. None of this is a knock on Bolt or Replit. Reusing a real design system faithfully, instead of an agent's own defaults, is a genuine upgrade, and shipping it twice in the same month says the market agrees on where the pain was. The gap is just upstream of both releases: an agent that reuses your system perfectly still needs somebody, or something, to hand it the real one first. --- # Webflow's AI Site Builder makes a design system. Not your brand's > Webflow's AI Site Builder generates a full token system from a prompt. Brand references get approximated, not copied, and it can't read a site built outside Webflow. Source: https://waalee.ai/blog/webflow-ai-site-builder-design-tokens-gap Published: 2026-09-17 · 4 min read · By The WAALEE Team Topics: Webflow AI Site Builder design system, Webflow AI website builder tokens, Webflow design tokens Flowkit, AI website builder brand colors, Webflow variables typography spacing, vibe coding design system Webflow pushed hard on its AI Site Builder this year, and the pitch this round is specific: type a prompt, get back not just pages but a whole design system, colors, type, and spacing, wired up as real Webflow variables. That's further than most AI builders go out of the box. Read the actual docs and support articles closely, though, and the design system it hands you is still an approximation of your brand, not a copy of it, and it can't touch a site you've already built anywhere else. Here's what the feature really does, and where the extraction still has to be exact. ## What actually gets generated Per [Webflow's own writeup](https://webflow.com/blog/ai-site-builder), the AI Site Builder establishes design tokens first, based on your prompt and any brand references you give it, then generates every page against those tokens. The output sits on top of Flowkit, Webflow's modular CSS framework: colors become global variables, typography becomes reusable text styles, spacing follows a consistent scale instead of arbitrary pixel values. Build a second page after that and it inherits the same system automatically. That's real infrastructure, not a one-off theme slapped on a single landing page. ## Reference your brand and it approximates, not copies The part worth reading twice is how it handles a brand reference. Describe a color, upload a logo, or point at a site you want the feel of, and the AI extracts a limited palette and a small set of type choices rather than attempting to replicate every visual detail. Named colors and hex codes get mapped into Webflow's theme system, not copied in exactly. That's a deliberate design choice, a restrained token set is easier to build a coherent site from than an exhaustive one lifted pixel for pixel. It also means the values that come out the other end are Webflow's best guess at your brand, not a measurement of it. ## And it can't read your actual site at all Push on the "existing site to draw inspiration from" language and you hit the real limitation: the AI Site Builder can't be applied to a site you've already built anywhere else, only a brand-new Webflow project, or one it already generated. So if your company's real brand only exists on a live production URL today, built in something other than Webflow years ago, there's no button that points the AI at that URL and regenerates a matching system from it. Webflow's own help center is candid about the consequence: "Lock your brand early. Set your real colors, fonts, and logo in the theme categories before you grow attached to the AI defaults." Translation: left alone, the defaults are generic, and turning them into your brand is still manual work. - A described color or uploaded logo gets interpreted into Webflow's theme system, not stored as an exact value. - An existing site named as inspiration gets a limited palette and a handful of type choices, not a full extraction. - The builder can't be pointed at an already-live, non-Webflow site to regenerate a matching system from it. - Left alone, the AI defaults hold until someone manually sets the real colors, fonts, and logo. ## Feed it exact values instead of a description None of this means the feature doesn't work, it means the quality of what it generates is capped by the quality of what you hand it. A vague color description gets you Webflow's interpretation of that description. An exact hex code, a real type scale, and a real spacing rhythm, extracted off the site where your brand actually lives today, gets mapped in far more precisely, because there's no approximation step left to run. If that source is a live URL nobody ever turned into a token file, pulling the real computed values out first is the difference between "inspired by your brand" and actually your brand. Three ways brand values get into a Webflow build, in practice: - [Webflow AI Site Builder](https://webflow.com/blog/ai-site-builder): Generates a full token system (colors, type, spacing) from a prompt and applies it across every page. Brand references get approximated into a limited palette, not copied exactly, and it can't be pointed at a site built outside Webflow. - [OpenDesign: Webflow plugin](https://open-design.ai/plugins/design-system-webflow/): A ready-made token set styled after Webflow's own marketing site look: Webflow Blue, its variable typeface, its spacing scale. A preset you can drop into any agent, not a way to pull tokens out of your own Webflow build. - [WAALEE](https://waalee.ai/): Paste your actual live URL and get the real colors, type scale, and spacing back as exact W3C tokens, ready to hand to Webflow's AI Site Builder as hex codes and named values instead of a vague description it has to interpret. None of this is a knock on what Webflow shipped. A prompt that generates a real, reusable token system instead of one-off inline styles is a genuine step up from most AI builders, and being upfront that it can't touch an existing outside site is more honest than pretending to. The gap is just the same one every AI design feature this year keeps leaving open: it's good at applying a brand once it has exact values. Getting those values exact is still on you. --- # Lovable shipped Design Systems. It still can't see your brand > Lovable's new Design Systems feature lets teams reuse one system across projects. None of its three ways to build one read tokens off a live URL. Source: https://waalee.ai/blog/lovable-design-systems-feature-brand-gap Published: 2026-09-15 · 4 min read · By The WAALEE Team Topics: Lovable Design Systems feature, Lovable AI design tokens, import design system into Lovable, AI coding agent design tokens, design system schema React, vibe coding brand colors Lovable shipped a real feature this cycle: [Design Systems](https://docs.lovable.dev/features/design-systems), a way to define a component library, tokens, and styling rules once and reuse them across every project in a workspace. It's a legitimate answer to the "how do ten different Lovable projects end up with one look" problem. It's not an answer to the question most people actually have the first time they open a design system feature: where do the real values come from. Read the docs closely and that gap is still there, it just moved one layer deeper. ## What Design Systems actually does A Lovable design system lives as its own project inside your workspace. Release it and Lovable generates a design-system.json schema (tokens, component catalog, variants, props, examples) plus rendered markdown docs for components, tokens, and library guidelines, with a version bump and a git commit each time. Connect another project to it and updates flow through automatically instead of getting redone by hand on every new build. That's a real fix for a real problem: teams running five or six Lovable projects who were previously re-explaining their palette in every single prompt. ## Three ways in, and none of them read a live URL Per Lovable's own docs, a design system starts one of three ways: built from scratch inside Lovable, imported from an existing npm package or public Git repository, or assembled from PDFs, markdown, screenshots, and written instructions you hand it directly. Notice what's missing from that list. There's no "paste your live site" option and no Figma connection, nothing that reads real computed colors, type, or spacing off a page that already exists. If your brand's actual hex codes and type ramp only live in a website nobody ever turned into a package, none of the three intake paths gets you there without a manual step first. - From scratch: fine if nobody's decided your brand yet, which is rarely true by the time you're building the third version of an app. - npm package or Git repo: only works if your tokens are already coded, versioned, and public, or you're on Enterprise, which unlocks private npm wrapping. - Docs and screenshots: Lovable infers values from what you hand it, so the accuracy ceiling is exactly however precisely you described a color in a PDF. ## The docs are honest about the ceiling One line in the documentation is worth sitting with: an existing project can't be converted into a design system. Once you've built an app and it already looks the way you want, you can't just point Lovable at it and say "make this the system." You have to go back to source, pull the values out by hand, and feed them back in through one of the three intake paths. That's not a bug, it's a reasonable scope decision for a first release. It also means the feature solves distribution, one system reused across many projects, without solving origination, where the first project's look actually comes from. ## Read the values off the page you already have If the real version of your brand only exists as a live, rendered website (built years ago in something other than Lovable, or handed off by an agency with no source files left), the fastest path into any of Lovable's three intake methods is the same move: extract the actual computed colors, type scale, and spacing off the rendered DOM first, then upload that as the documentation Lovable ingests, or wire it into the from-scratch flow as real numbers instead of a guess. That turns "docs and screenshots" from a lossy description into an exact one. Three approaches to getting real tokens into a system an AI builder can reuse: - [Lovable Design Systems](https://docs.lovable.dev/features/design-systems): Reuses one system across a whole workspace once it exists. Three intake paths (scratch, npm/Git, docs), none of which read a live URL directly. - [OpenDesign](https://open-design.ai/): Agent-native alternative built around a single DESIGN.md plus tokens.css and manifest.json, compiled into an immutable versioned system. Same shape of problem: it still assumes someone already wrote the tokens down. - [WAALEE](https://waalee.ai/): Paste a live URL and get the real colors, type scale, and spacing back as W3C tokens in seconds, ready to hand to Lovable's docs-and-screenshots intake, or anywhere else, as exact values instead of a description. None of this is a knock on shipping Design Systems. Reuse across projects is a real, overdue feature, and being upfront that an existing project can't just become the system is more honest than a lot of "one-click" pitches in this space. The point is just to know which half of the problem it solves. Distribution and origination are different jobs, and Lovable just fixed the first one. --- # Google open-sourced DESIGN.md. Here's what's actually in the spec > Google Labs made its DESIGN.md format open source and Apache-2.0 licensed. It's a real spec now, not a convention. Here's what changed and what still has to be filled in by hand. Source: https://waalee.ai/blog/google-design-md-open-source-spec Published: 2026-09-13 · 5 min read · By The WAALEE Team Topics: DESIGN.md format, Google DESIGN.md spec, design tokens for AI coding agents, DTCG design tokens, AI agent design system file, Tailwind v4 design tokens On April 21, 2026, Google Labs [open-sourced DESIGN.md](https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-design-md/) under Apache-2.0, turning what had been an internal convention for its Stitch design tool into an actual format spec with a CLI and a linter. The [GitHub repo](https://github.com/google-labs-code/design.md) crossed 10,000 stars in eight days. That's a fast validation for a markdown file format, and it means the loose "drop a DESIGN.md in your repo root" pattern a few teams were already improvising is now something closer to a standard, with rules an agent (and a linter) can actually check. ## One file, two jobs The structure is the interesting part. A DESIGN.md file carries YAML front matter with the machine-readable tokens (exact hex codes, font sizes, spacing values, corner radii, component styles) and then, in the same file, markdown prose explaining the rationale behind them: when to use which weight, what the spacing rhythm is for, the taste rules a token file alone can't express. Earlier attempts at this problem, including a similarly-named convention some shadcn theme builders were already using, picked one or the other: either a token file with no explanation, or a brief with no exact values. Google's version asks for both, in one place, so an agent reading the file gets the number and the reason at the same time. ## It's not inventing a new token language The tokens themselves follow the [W3C Design Tokens (DTCG) structure](https://www.designtokens.org/tr/drafts/format/), and the CLI exports straight to `tokens.json` and to a Tailwind v4 theme, using the CSS-variable namespaces Tailwind already expects: `--color-*`, `--font-*`, `--text-*`, `--radius-*`, `--spacing-*`, and a few more. That's a sensible choice. It means a DESIGN.md file isn't a competing standard sitting next to DTCG, it's a wrapper around it, one that adds the human-readable half most agents were missing without asking teams to learn a second token schema on top of the one that already went stable last October. ### What's genuinely new here - A formal, versioned spec instead of an ad hoc convention, with Apache-2.0 licensing behind it. - A CLI and linter that can actually validate a DESIGN.md file, not just eyeball it. - Direct export to DTCG-format tokens.json and to a Tailwind v4 theme block, no manual translation step. - Prose and tokens living in the same file, so an agent doesn't have to cross-reference two documents to get both the value and the intent. ## The part it still doesn't do The spec is explicit that it's at alpha, and that's honest, but the bigger gap isn't version stability. It's that DESIGN.md, like every brief format before it, describes a design system that already exists somewhere in someone's head or Figma file. It's a container, not a generator. If your brand's actual hex codes, type ramp, and spacing scale were never written down precisely, a DESIGN.md file just gives you a nicely structured place to guess at them. The linter will happily validate a spacing scale that's wrong, because "valid YAML" and "your actual brand" are two different questions, and the CLI only checks the first one. ## Filling it in without guessing The fastest way to populate a DESIGN.md file with real numbers, rather than plausible ones, is to pull them from a page that already renders your brand: your own live site, or a reference whose look you're building toward. Read the computed colors, the actual font sizes and line-heights, the real spacing rhythm off the rendered DOM, and you've got the machine-readable half of the file done correctly on the first pass. The prose half (why the accent is used sparingly, when to reach for the secondary weight) is still yours to write, because that judgment call doesn't live in a browser's computed styles. But you're writing rationale for values you know are right, not values you made up under deadline. Three ways DESIGN.md gets its values filled in, in practice: - [google-labs-code/design.md](https://github.com/google-labs-code/design.md): The official spec, CLI, and linter. Validates structure and DTCG compliance. Doesn't know your brand colors; you (or another tool) still have to supply them. - [awesome-design-md](https://github.com/VoltAgent/awesome-design-md): A fast-growing community collection of example DESIGN.md files and patterns, useful for seeing the format in practice before writing your own from scratch. - [WAALEE](https://waalee.ai/): Paste a live URL and get the real colors, type scale, spacing, and radii as W3C DTCG tokens in seconds, ready to drop into the front matter of a DESIGN.md file instead of eyeballing them. None of this is a knock on the spec, an open, lintable format for something every AI coding team was already improvising badly is a real improvement, and it's the right instinct to pair tokens with rationale in one file. The honest caveat is the same one that applies to every brief format so far: a well-formed DESIGN.md with the wrong numbers in it is still the wrong numbers, just tidier. Get the values right first, from a source you trust, then let the spec do what it's actually good at. --- # Claude Code Skills can extract your design system now. Here's the catch > A growing marketplace of Claude Code Skills promises to pull design tokens straight from a URL or codebase. Great, if you already have Claude Code installed and open. Source: https://waalee.ai/blog/claude-code-skills-design-system-extraction Published: 2026-09-11 · 4 min read · By The WAALEE Team Topics: Claude Code Skills design system, Claude Code skill marketplace, extract design tokens skill, design system extractor Claude, AI agent skill design tokens, vibe coding design system Since [Claude Code Skills](https://claudemarketplaces.com/skills/category/design-ui) opened up as a marketplace, a small wave of design-extraction skills has shown up in it, packaged markdown instructions that teach an agent how to reverse-engineer a design system from a URL or a codebase. It's a real step forward from typing "match this site's vibe" into a prompt. It's also gated behind a setup step most of the pitch decks skip past: you need Claude Code installed, open, and pointed at a project before any of it runs. ## What these skills actually do The pattern across the marketplace listings is consistent. [arvindrk/extract-design-system](https://github.com/arvindrk/extract-design-system) is an open-source CLI, distributed as an installable skill for Claude, Cursor, and Codex, that reads colors, typography, spacing, border radius, and shadows off a public site and writes them out as JSON and CSS custom properties. [AI UX Playground's Extract Design System skill](https://aiuxplayground.com/skills/extract-design-system/) does the same job framed as a repeatable agent workflow rather than a one-off script. Point either at a URL, and the agent crawls it, reads the rendered styles, and produces a token file it can then apply to whatever you're building next. ## The part that only shows up once you try it A skill is not a standalone tool. It's a set of instructions that only runs inside an agent that already has Skills support turned on, which today means Claude Code, Cursor, or Codex, installed locally, with a terminal open and a project directory to work in. That's a fine assumption if you're a developer mid-session in an IDE. It's a real barrier if you're a designer, a founder, or anyone who wants to check a competitor's palette or start a mood board before a codebase even exists. - You need Claude Code, Cursor, or Codex installed and configured with Skills before any extraction skill runs at all. - Most of these skills execute as CLI scripts under the hood, so a failed dependency or a site that blocks headless browsers fails silently in a terminal, not in a UI that tells you what went wrong. - The output is a file on disk. Useful once you're in a repo, less useful if you just want to look at a palette on your phone before a call. - None of them ship a hosted, no-install version, because a skill's whole design is to run inside an agent you already have open. ## Where the skill approach genuinely wins None of this is a knock on the skills themselves. If you're already living inside Claude Code on a real project, a skill that extracts tokens without leaving the terminal, in the same session where you're about to build the UI, is a real time save. It skips the context switch of opening a browser tab, running an extractor, and pasting the output back in. For a developer mid-build, that loop is the whole point of Skills existing in the first place. ## For everyone else, the browser is still faster The gap these skills leave open is the moment before a project exists: benchmarking a competitor, collecting three references for a pitch, or just checking what a site's actual accent color is before you've decided which AI builder you're even using. For that, a web-based extractor that needs nothing installed does the same underlying job (headless browser, rendered DOM, real computed styles) without asking you to set up an agent first. Three ways to get a token file out of a live site, depending on what you already have open: - [extract-design-system (arvindrk)](https://github.com/arvindrk/extract-design-system): Open-source CLI and Claude/Cursor/Codex skill. Outputs JSON and CSS variables. Requires the CLI installed and, for the skill version, an agent with Skills enabled. - [AI UX Playground: Extract Design System](https://aiuxplayground.com/skills/extract-design-system/): A packaged Claude Code Skill for the same job, framed as a repeatable in-session workflow. Same prerequisite: Claude Code open with Skills turned on. - [WAALEE](https://waalee.ai/): Paste a URL in the browser, no install, no agent setup. Returns colors, type, spacing, and W3C tokens plus AI-ready prompts for Claude, Lovable, v0, Cursor, and Bolt in seconds. The honest read: Skills are a good delivery mechanism for a developer already deep in a session, and the marketplace around them is only going to get more crowded. But a skill needs a host, and the host needs installing first. If the question is just "what does this site's design system actually look like," asked before you've opened an editor, a browser-based extractor still gets you there in fewer steps. Use whichever one matches where you already are, not where the demo assumes you are. --- # v0 Design Systems 2.0 wants your tokens. Here's the shape it expects > v0's Design Systems 2.0 will import your tailwind config and globals.css directly. The catch: it assumes shadcn/ui's CSS variable standard, and most sites don't have that file yet. Source: https://waalee.ai/blog/v0-design-systems-2-token-shape Published: 2026-09-09 · 4 min read · By The WAALEE Team Topics: v0 Design Systems 2.0, v0 by Vercel design tokens, shadcn CSS variables theming, import design system into v0, AI website builder design tokens, vibe coding design system [v0 by Vercel shipped Design Systems 2.0](https://v0.app/docs/design-systems-2) 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](https://vercel.com/blog/working-with-figma-and-custom-design-systems-in-v0) assumes your tokens already follow the [shadcn/ui CSS variable standard](https://ui.shadcn.com/docs/theming). 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](https://www.figma.com/blog/introducing-figma-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](https://github.com/figma/mcp-server-guide/blob/main/skills/figma-generate-library/references/code-connect-setup.md) 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](https://v0.app/docs/design-systems-2): 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](https://www.figma.com/blog/introducing-figma-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](https://waalee.ai/): 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. --- # Style Dictionary v5 shipped. Three things quietly broke your tokens > Style Dictionary v5 needs Node 22, tightens what a reference can point to, and zeroheight just retired its legacy export. Here's what actually changes in your pipeline. Source: https://waalee.ai/blog/style-dictionary-v5-breaking-changes Published: 2026-09-07 · 5 min read · By The WAALEE Team Topics: Style Dictionary v5, design token migration, DTCG design tokens 2025.10, Style Dictionary breaking changes, zeroheight legacy tokens, design tokens for AI coding agents [Style Dictionary v5](https://styledictionary.com/versions/v5/migration/) is out, and if you maintain a token pipeline that feeds Claude, Lovable, v0, Cursor, or Bolt, it's worth a slower look than a changelog skim. The headline is that it aligns with [DTCG 2025.10](https://styledictionary.com/info/dtcg/), the design tokens spec that went stable last October. The part that actually breaks builds is three smaller, specific changes buried in the migration guide, and a fourth one that just hit a token management tool you might already be using. ## References can only point to a token now, not a group In earlier versions, a reference like `{foo}` could resolve to a whole group of tokens, or `{foo.nested.attributes}` could reach into a sub-property partway down the tree. [The v5 migration guide](https://styledictionary.com/versions/v5/migration/) closes both doors: a reference now has to point at an actual token, meaning its `$value`, full stop. If your tokens.json ever aliased a category instead of a specific value, expecting Style Dictionary to figure out which leaf you meant, that file no longer builds. It has to be rewritten to reference the leaf token directly. ## The reference syntax itself is no longer yours to configure v4 and earlier let you customize the brackets and separator used in references, so a team could run `$foo.bar` instead of `{foo.bar}` if that fit their existing files better. v5 removes that option. The opening brace, closing brace, and dot separator are fixed to match the DTCG spec exactly. That's a reasonable trade for interoperability, one less way for a tool to silently disagree with another tool about what a reference looks like, but it means any pipeline that leaned on a custom syntax needs a find-and-replace pass before it builds again. ## Node 22 is now the floor Style Dictionary v5 requires Node.js 22 or newer, because it uses `Set.prototype.union` internally to speed up how references get resolved. That's a small technical detail with a real operational consequence: a CI pipeline still pinned to Node 18 or 20 for a token build step will fail outright, not silently. Worth checking before you bump the package version and walk away. ## zeroheight just retired its legacy export, this month Separately from the library itself, [zeroheight's token manager](https://help.zeroheight.com/hc/en-us/articles/48049028236187-Migrating-to-Style-Dictionary-v5-in-tokens-automation) upgraded its export pipeline to run on Style Dictionary v5, and as part of that, it retired the older DTCG JSON (legacy) and Style Dictionary export formats starting this September. Existing exports in the old format keep working, but you can no longer create a new token set output or a new URL export in it. If your AI builder's setup script points at a saved zeroheight export URL from a year ago, this is worth checking now rather than after a build quietly stops resolving colors. - A reference to a token group, not a leaf value, stops building under v5. - A custom reference syntax (anything other than `{}` and `.`) stops building under v5. - A CI runner on Node 18 or 20 fails the build step outright, not silently. - A zeroheight export URL created before this month may be sitting on a format that new token sets can no longer be exported to. ## Why this matters more than a normal dependency bump A version bump in most tools breaks a build loudly, you see the error, you fix the syntax, you move on. Token pipelines are sneakier, because a broken reference doesn't always fail the build, sometimes it resolves to nothing and your CSS custom property comes out empty. The agent building your UI still runs. It just quietly gets no color instead of your color, and you find out when the page looks unstyled instead of wrong. That failure mode is exactly why it's worth testing your token build against v5 deliberately, rather than finding out from a broken deploy. Where this actually lands depending on how you get your tokens: - [Style Dictionary v5](https://styledictionary.com/versions/v5/migration/): The transform engine itself. Real breaking changes: leaf-only references, fixed syntax, Node 22 floor. Worth testing before you upgrade in place. - [zeroheight tokens](https://help.zeroheight.com/hc/en-us/articles/48049028236187-Migrating-to-Style-Dictionary-v5-in-tokens-automation): Legacy export formats retired for new token sets starting September 2026. Old export URLs still resolve, but nothing new can be created in the old shape. - [WAALEE](https://waalee.ai/): Extracts tokens fresh from a live URL in current DTCG 2025.10 shape, so there's no legacy export or old reference syntax to migrate in the first place. None of this means skip the upgrade. DTCG alignment is the right direction, and a stricter reference model catches real mistakes that used to fail silently. It just means treat a token pipeline upgrade like a schema migration, not a patch bump: rebuild your tokens against v5 in a branch, diff the output, and check that every color your app depends on actually still resolves before you ship it. --- # Cursor's Design Mode fixes precision. Not your default palette > Cursor's Design Mode lets you click, draw, or talk an agent through a UI fix on a live page. It's a real upgrade for iteration. It still starts every first draft from Cursor's own defaults. Source: https://waalee.ai/blog/cursor-design-mode-precision-not-palette Published: 2026-09-05 · 4 min read · By The WAALEE Team Topics: Cursor Design Mode, Cursor agent UI editing, AI coding agent design tokens, Cursor default theme, Figma Skills design tokens, AI first draft design system Cursor's [Design Mode](https://cursor.com/blog/design-mode) shipped inside the Agents Window in April 2026 and got a real upgrade in June: click an element on a live page, draw around a section, or just talk, and the agent sees the code, the surrounding layout, and the visual relationships behind whatever you pointed at. It's a genuinely better way to give an agent feedback than typing "make the header bigger" and hoping it finds the right div. It's also solving a narrower problem than it looks like it's solving, and the part it leaves alone is the part that decides whether your app looks like your brand or like Cursor's demo. ## What Design Mode actually fixes Before Design Mode, correcting an AI-generated UI meant describing it in words, and words are a lossy channel for anything spatial. "The card padding is off" could mean six different things depending on which card, which side, and by how much. [Cursor's docs](https://cursor.com/docs/agent/design-mode) describe the fix plainly: point at the actual element in the rendered browser, and the agent gets the DOM node, the component it maps to, and the styles already applied, no translation through prose required. The [June update](https://cursor.com/changelog/design-mode-improvements) pushed it further, letting you queue several such corrections across different elements while the agent is still working through the first one. ## It's an iteration tool, not a starting-point tool Notice what all of that requires: a UI that already exists, rendered, on a page you can click into. Design Mode has nothing to say about the moment before that, when the agent is generating the first draft from an empty prompt. At that point there's no element to point at yet, so the agent falls back to whatever it defaults to absent an opinion, which for most AI coding tools in 2026 is still some flavor of Tailwind's stock palette and shadcn's default radius. Design Mode makes the second pass sharper. It doesn't touch the first one. - Design Mode shortens the loop between "that's wrong" and "that's fixed," which is real, compounding value over a project. - It has no model of your brand: no saved palette, no type scale, no spacing rhythm it reaches for by default. - Every new page, new project, or fresh `cursor agent` session starts from the same blank defaults Design Mode then helps you correct by hand, one click at a time. - The correction time you save on page two is time you're still spending re-explaining colors and type on page one. ## Figma's Skills have the same shape Figma shipped something structurally similar in March: [built-in Skills](https://www.figma.com/blog/the-figma-canvas-is-now-open-to-agents/) for its MCP server, markdown files that teach an agent team-specific conventions instead of generic ones. One of the nine launch skills is `/sync-figma-token`, which syncs design tokens between code and Figma variables with drift detection. It's a good tool, and it's still a sync utility: it keeps two places in agreement about values that already exist somewhere. It doesn't generate the values, and if your team never defined a token in Figma to begin with, there's nothing for it to sync. ## Give the agent the palette before it needs correcting Both tools are pointed at the same gap from opposite ends: Design Mode makes the fix faster once something's wrong, Figma Skills keeps two systems in sync once tokens exist. Neither one manufactures the tokens themselves, which means the fastest actual fix is upstream of both: extract your real colors, type scale, spacing, and radius before the first prompt, so the agent's default draft is already close, and Design Mode ends up correcting typos instead of correcting a brand. Three tools, three different points in the same workflow: - [Cursor Design Mode](https://cursor.com/blog/design-mode): Click, draw, or speak a correction on a live rendered page. Fast, precise iteration on UI that already exists. No opinion about first-draft colors or type. - [Figma Skills (sync-figma-token)](https://www.figma.com/blog/the-figma-canvas-is-now-open-to-agents/): Keeps code and Figma variables in agreement with drift detection, once both sides already have tokens defined. Doesn't originate the values. - [WAALEE](https://waalee.ai/): Paste your own live site or a reference and get real colors, type scale, spacing, and radius as W3C tokens before you write the first prompt, so the agent's first draft starts from your brand instead of Cursor's defaults. None of this is a knock on Design Mode, it's a genuinely useful feature and worth turning on. The point is just to be honest about which half of the problem it solves. It makes fixing a UI faster. It doesn't make the first version of that UI look like you, and that part still has to come from somewhere real, once, before the agent starts guessing. --- # shadcn's new MCP server fixes hallucinated components. Not your theme > shadcn/cli v4 shipped an MCP server and shareable presets in 2026. Agents stopped inventing components that don't exist. The look is still whichever preset you picked. Source: https://waalee.ai/blog/shadcn-mcp-server-not-your-theme Published: 2026-09-03 · 4 min read · By The WAALEE Team Topics: shadcn MCP server, shadcn cli v4 presets, shadcn theme customization AI, AI agent hallucinated components, shadcn design tokens, shadcn init preset shadcn/ui shipped [cli v4](https://ui.shadcn.com/docs/changelog/2026-03-cli-v4) in March 2026, and the headline feature is an MCP server that lets Claude, Cursor, and Windsurf query the real component registry instead of generating shadcn-flavored code from memory. It's a genuine fix for a genuine problem. It's also not the problem most people mean when they say their AI build looks generic, and the preset system that shipped alongside it can make that second problem worse before it makes it better. ## What the MCP server actually fixes Before the MCP server, an agent asked for a shadcn `DataTable` or `Combobox` was working from training data, which meant plausible-looking code that sometimes referenced props that don't exist, or a component API from an older version of the library. The MCP server closes that gap directly: an agent can list what's actually in your registry, pull the current source for a component, and run the install command itself, so the code it writes matches what's really there. [One integration guide](https://tokenmix.ai/blog/shadcn-mcp-frontend-component-integration-guide-2026) frames the win correctly: fewer hallucinated props, fewer broken imports, less time spent debugging code that looked right and wasn't. That's a real, narrow improvement, and it's worth having. ## Presets solve a different problem, and it's not yours cli v4 also introduced presets: a way to bundle an entire look (colors, radius, fonts, theme) into a shareable code, built and previewed at shadcn/create, then applied with `init --preset` or swapped later on an existing project. It's a smart answer to "stop shipping the unedited default theme," and if you're picking between ten strangers' presets instead of one default palette, that is technically more variety. It is not your brand. A preset is still somebody else's design decision, just one of several instead of the only one. Run the same preset code twice, on two different projects, and you get the same look twice. ## The line that matters: "MCP-generated code may fight your overrides" Here's the part worth reading twice. The same integration guide has a pitfall section, and it says plainly: if you've heavily customized your shadcn theme, MCP-generated code may fight your overrides, and the fix offered is to spell out your customizations in the prompt every time. That's an honest admission that the MCP server has no model of your actual design decisions. It knows the component API. It doesn't know that your `--radius` is 2px because your brand is sharp-cornered, or that your accent color was chosen for a reason, so it keeps generating against the shadcn default unless you re-explain your theme in every prompt. - The MCP server fixes component correctness: real props, real imports, real install commands. - Presets fix theme laziness: nobody has to accept the unedited default anymore. - Neither one carries your actual brand decisions from one prompt, or one project, to the next. - Without that, an agent still needs to be told your colors, type, spacing, and radius every single time, in every single prompt. ## Give the agent your theme once, in a form it keeps The fix isn't a bigger prompt repeated forever, it's a token file the agent reads instead of being told. Extract your real colors, type scale, spacing, and radius, either off your own live site or off a reference whose look you're building toward, and drop them into `globals.css` as the values shadcn's theme layer expects. Now the MCP server's component code and your theme aren't fighting: the components come from the registry, correct and current, and the values they render with are actually yours, not a preset code you picked off a gallery. Three pieces of the same stack, each solving a different slice of the problem: - [shadcn/cli v4 + MCP server](https://ui.shadcn.com/docs/changelog/2026-03-cli-v4): Fixes component hallucination: agents query the real registry instead of guessing from training data. Doesn't know or manage your theme values. - [shadcn presets (shadcn/create)](https://ui.shadcn.com/docs/changelog/2026-04-preset-commands): Bundles a shareable look (color, radius, font) so you're not stuck on the bare default. Still someone else's preset until you swap in your own values. - [WAALEE](https://waalee.ai/): Paste your own live URL or a reference site and get the actual colors, type scale, spacing, and radius as W3C tokens, ready to drop into shadcn's theme layer instead of a stranger's preset code. None of this is a knock on cli v4, it's a real step forward and worth updating for. But it's worth being precise about which step it took. It made agents better at writing shadcn's components. It didn't make them better at knowing what your brand looks like, and that's still the part you have to bring yourself, once, in a form that sticks. --- # Tailwind v4 killed the JS config. Your AI builder still guesses > Tailwind v4 moved tokens into a CSS-first @theme block and switched to OKLCH. That fixed one problem and left the default-palette problem untouched. Source: https://waalee.ai/blog/tailwind-v4-theme-tokens-for-ai-builders Published: 2026-09-01 · 4 min read · By The WAALEE Team Topics: tailwind v4 design tokens, tailwind theme directive AI, oklch color tailwind css, tailwind css4 default colors, AI coded app default palette, design tokens for tailwind v4 Tailwind v4 replaced `tailwind.config.js` with a CSS-first `@theme` block, and it switched every default color to [OKLCH](https://tailwindcss.com/docs/colors). Both changes are good news for AI coding tools, and neither one stops your Claude, Lovable, v0, Cursor, or Bolt build from shipping with Tailwind's own palette instead of yours. Here's why, and what actually closes the gap. ## The JS config is gone, and that's the right call for AI In v3, your design tokens lived inside a JavaScript object nested in `tailwind.config.js`, a file an AI agent had to parse as code before it could even see your palette. [Tailwind's own docs](https://tailwindcss.com/docs/theme) now put tokens in a plain `@theme` block, written as CSS custom properties, sitting in your global stylesheet. That's a meaningfully better fit for a model: it reads CSS natively and reliably, where it sometimes trips on which config file wins, which import path is live, or whether a project is even on v3 or v4. [MatchKit's guide to the change](https://www.matchkit.io/blog/design-tokens-tailwind-v4) makes the same point plainly: agents find tokens by reading your CSS file directly, or by being told the token names in a rules file, and a `@theme` block is the more legible of the two. ## OKLCH is the default now, and that changes what a token even looks like The other headline change is quieter but touches every color in the framework: Tailwind v4's entire default palette is defined in [oklch()](https://tailwindcolor.tools/guides/tailwind-v4-color-system) instead of hex or rgb. OKLCH is perceptually uniform, meaning equal numeric steps look like equal visual steps, which is why the built-in shade ramps look more consistent in dark mode and on wide-gamut screens. Tailwind's docs recommend writing your own custom colors in OKLCH too, to match. Practically, this means a token file you hand-typed in hex a year ago no longer matches the format your framework's own defaults are written in, and a straight find-and-replace on colors isn't as safe as it used to be. ## None of that stops the default palette from shipping Here's the part that doesn't get fixed by any of the above: `@theme` is just a place to put your tokens. If you never fill it in, Tailwind falls back to its own 22-hue, 11-shade default palette, and so does every agent generating classes against it. Ask Claude Code or Cursor for a signup form and, absent an opinion, you'll get `bg-indigo-600` and `text-gray-500`, Tailwind's defaults, not a decision anyone made about your brand. The CSS-first format made the token file easier for a model to read. It didn't make the model any more likely to fill it with something that isn't the stock palette. - A blank or default `@theme` block reads as "no brand," the same way a blank system prompt does. - OKLCH values are harder to eyeball than hex, which makes hand-authoring them error-prone under time pressure. - Two-layer setups (raw tokens in one file, Tailwind utilities generated from them in another) are the recommended pattern now, per [Clearly Design's walkthrough](https://clearly.design/articles/ai-ready-ds-4-design-tokens-tailwind-v4), but someone still has to populate the raw layer. ## Filling the block: three ways to get real values in The `@theme` block needs real values before an agent can apply them. Here's how each approach gets you there: - [Hand-write it](https://tailwindcss.com/docs/theme): Tailwind's own docs on the @theme syntax. Free, and correct once you've decided your brand's OKLCH values by hand, shade by shade. - [MatchKit's token guide](https://www.matchkit.io/blog/design-tokens-tailwind-v4): A thorough walkthrough of how to structure tokens for v4 and wire them so agents pick them up. Teaches the pattern; you still supply the colors. - [WAALEE](https://waalee.ai/): Paste a live URL and get the real OKLCH-ready colors, type scale, and spacing straight off the rendered page, exported as W3C tokens plus a prompt for Claude, Lovable, v0, Cursor, and Bolt. Drop the values into @theme instead of guessing them. Tailwind v4 fixed the plumbing. The `@theme` block is a better place for tokens to live than a JS config ever was, and OKLCH is a better color space than hex for building consistent shade ramps. But a better pipe still needs something real flowing through it. Whether you fill it in by hand, follow a guide, or pull the values off a page you already like, the point is the same one it's always been: an agent applies a decision, it doesn't invent one. --- # Why every AI-coded app looks like shadcn/ui (and the real fix) > shadcn/ui is now the default kit for Claude, Lovable, v0, Cursor and Bolt. That's why so many AI apps share one look. Here's what actually breaks the pattern. Source: https://waalee.ai/blog/why-ai-apps-look-like-shadcn Published: 2026-08-31 · 4 min read · By The WAALEE Team Topics: shadcn ui looks generic, why AI apps look the same, shadcn theme tokens, fix generic AI design, DESIGN.md shadcn, vibe coding design system Open ten apps built this year with Claude, Lovable, v0, Cursor or Bolt and at least six of them will share a face: the same rounded cards, the same muted slate palette, the same Inter type, the same soft shadow. That's not a coincidence and it's not a limitation of the models. It's [shadcn/ui](https://ui.shadcn.com/), and by now it's less a component library than the default skin of AI-generated software. ## shadcn didn't get generic. The defaults did. shadcn/ui was never meant to be a finished look, it ships as copy-pasted source you're supposed to edit. But almost nobody does. As one recent breakdown of the problem put it, people "run the install command, accept the default theme, accept the default radius, accept the default Inter font, and start building." That would be a minor style tic if a human made the call once per project. It compounds because AI agents do the same thing on every project, every time, gravitating to whatever pattern shows up most in their training data, which by now is unedited shadcn. ## The five tokens that actually decide how it looks The fix isn't a new component kit, it's five CSS variables shadcn already exposes and almost nobody touches: - Neutral colors: swap the default slate/zinc grey for something with an actual undertone. - Border radius: commit to sharp, soft, or pill. The safe middle ground is what reads as "default kit." - Typography: pick a real pairing instead of Inter doing every job on the page. - Accent color: one saturated color doing real work, not a muted brand-safe blue. - A signature detail: one texture, shadow, or easing curve shadcn doesn't ship with. Change those five and the components underneath are untouched, but every screen your agent generates stops looking like the demo. The catch is you still have to decide what those five values are, and "pick something that isn't grey" is not a design system. ## A brief tells the agent what to feel. It still needs real values. The best response to this so far is [DESIGN.md](https://www.shadcnblocks.com/blog/shadcn-theme-design-md), a plain-markdown brief that ships alongside a theme and describes intent, not just hex codes: color roles, when to use which weight, spacing rhythm, the "taste rules" that keep an agent from improvising. Drop it in your repo root or `.agents/` folder and Claude or Cursor read it before generating a new screen. It's a real improvement, agents stop guessing hierarchy and density from nothing. It also has a ceiling. DESIGN.md describes a look somebody already decided on, usually by hand, usually once. If your brand doesn't have that decision made yet, or you're trying to match a reference site's actual feel rather than write a new one from scratch, a prose brief is still starting from a blank page. It tells the agent how to feel about colors it doesn't have yet. ## Give it real values before it has to guess The more direct fix is to skip writing the brief and pull the actual values from somewhere real: your own site if you have one, or a reference whose look you're trying to hit. That's the same five tokens above, plus type scale and spacing, read straight off a rendered page instead of typed in from memory. Feed those into your shadcn `globals.css` and the agent isn't improvising a personality anymore, it's applying a decision that already exists. ## Where each approach actually helps None of these are competitors, they solve different parts of the same problem: - [DESIGN.md (Shadcnblocks)](https://www.shadcnblocks.com/blog/shadcn-theme-design-md): A markdown brief for a theme you've already designed. Best once your look is decided and you want agents to stop drifting from it. - [The five-token rewrite](https://freedesignmd.com/blog/shadcn-looks-generic): The minimum manual fix: five CSS variables to override by hand so your build stops reading as unedited shadcn. - [WAALEE](https://waalee.ai/): Paste a live URL and get the actual color, type, spacing and radius values off the rendered page as W3C tokens, ready to drop into shadcn's globals.css, plus a prompt for Claude, Lovable, v0, Cursor or Bolt. No blank page. shadcn is a fine foundation, the component quality is real and that's not what's generic. What's generic is shipping it untouched. Whether you write the brief by hand or extract the values from a reference, the point is the same: the agent needs a decision to apply, not defaults to fall back on. --- # Figma's MCP server only works if you own the Figma file > Figma's Dev Mode MCP server feeds real tokens straight into Claude Code and Cursor. Great, if you have access to the file. Here's the fix when you don't. Source: https://waalee.ai/blog/figma-mcp-server-without-a-figma-file Published: 2026-08-29 · 5 min read · By The WAALEE Team Topics: Figma MCP server, Figma Dev Mode MCP, extract design tokens without Figma, design tokens for Claude Code, AI coding design system extractor, Figma MCP alternative Figma shipped its [Dev Mode MCP server](https://www.figma.com/blog/introducing-figma-mcp-server/) last year, and by now most AI coding tools know how to talk to it. Point Claude Code, Cursor, or Windsurf at a Figma file and the agent pulls real component structure, variable names, and token values instead of squinting at a screenshot. It's a genuine upgrade over the old copy-paste-a-hex-code workflow. It's also completely useless the moment you don't have the Figma file, and that happens more often than the demos let on. ## What the MCP server actually fixes The problem it solves is real. Before Dev Mode MCP, handing a design to an AI coding agent meant a screenshot, or a prose description, or a developer eyeballing spacing in the browser inspector and rounding to the nearest 8px. The MCP server exposes the file as structured data: layer tree, variable definitions, component variants, the actual token names your design team used. An agent reading that produces on-brand code instead of a plausible guess. ## The catch nobody puts in the demo The server only reaches files you already have permission to open. [Figma's own docs](https://developers.figma.com/docs/figma-mcp-server/rate-limits-access/) are blunt about it: your client can't navigate to a URL and pull tokens on your behalf, it needs a node-id from a file you can view or edit, and if you're on a Starter plan or a view-only seat you're capped at a handful of tool calls a month. None of that is a bug. It's just a different problem than the one most people reach for an extractor to solve. - A competitor's site you want to benchmark against, with no Figma access, obviously. - An inspiration site you found in the wild that was never yours to open. - Your own client's old site, where the Figma file is gone, on someone's laptop, or never existed because it was built straight in code. - An agency handoff where you got a live URL and a login, not a design file. ## Read the tokens off the page instead None of those situations are actually blocked, they just need a different entry point. If you can't get structured tokens out of a design file, get them out of the rendered result of that design file instead: point a headless browser at the live URL and read the computed styles straight off the DOM, after fonts, CSS, and layout have all resolved. That's not a workaround in the hacky sense. It's working from the same source of truth Figma itself is ultimately rendering toward, just from the other end. Done right, the output looks the same as what Dev Mode MCP hands you: a real color palette, a type scale, a spacing rhythm, and W3C DTCG-format tokens your AI builder can consume directly, no re-typing hex codes into a prompt. ## Three ways to get tokens in, with or without the Figma file Here's an honest comparison of where each approach actually fits: - [Figma Dev Mode MCP](https://www.figma.com/blog/introducing-figma-mcp-server/): The best option when you own or have edit/view access to the file. Live, bidirectional, and it understands components and variants, not just visual style. Gated by seat type and, on lower plans, a monthly call cap. - [designlang](https://www.designlang.app/): Open-source CLI that points a headless browser at any URL and reads the DOM directly, no Figma account needed. Emits DTCG tokens plus a bundled MCP server for Claude Code and Cursor. - [WAALEE](https://waalee.ai/): Paste any live URL in the browser, get colors, type, spacing, W3C tokens, and AI-ready prompts for Claude, Lovable, v0, Cursor, and Bolt back in seconds. No install, no Figma access, no seat to buy. ## Use the one that matches what you actually have If you're on your own team's file with edit access, Dev Mode MCP is the right default, it's closer to the design intent and it can write back to the canvas. If what you have is a URL, whether it's a competitor, an old client site, or a reference you admire, DOM-based extraction gets you to the same kind of token file without needing anyone's permission to open anything. Most teams end up using both: Figma MCP for the system they own, a live-URL extractor for everything they're studying but don't. --- # The W3C design tokens spec just went stable, and hex codes broke > DTCG 2025.10 is the first stable Design Tokens Format Module. It also changes how color values are written. Here's what actually changed. Source: https://waalee.ai/blog/dtcg-2025-color-format-change Published: 2026-08-27 · 5 min read · By The WAALEE Team Topics: W3C design tokens 2025.10, DTCG design tokens spec, design token color format change, design tokens format module, design token extractor for AI coding, W3C DTCG stable release On October 28, 2025, the [W3C Design Tokens Community Group](https://www.w3.org/community/design-tokens/2025/10/28/design-tokens-specification-reaches-first-stable-version/) shipped 2025.10, the first stable version of the [Design Tokens Format Module](https://www.designtokens.org/tr/drafts/format/). Twenty-plus companies signed off on it, including Adobe, Figma, Google, Salesforce, and Shopify. That's the headline. The part that actually touches your codebase is smaller and easy to miss: the way you write a color value changed. ## The part that breaks: color is no longer just a string Before 2025.10, a token file writer could get away with a hex string and call it done: `{ "$value": "#4f9bf5" }`. The stable [color module](https://www.designtokens.org/tr/drafts/color/) requires `$value` to be an object with a `colorSpace` and its component channels, with hex allowed only as an optional fallback alongside it. That's not cosmetic. It's how the spec adds real support for Display P3 and Oklch, the wide-gamut spaces most design tools already use internally but couldn't express portably before now. This isn't hypothetical friction. [Penpot's own tracker](https://github.com/penpot/penpot/issues/9305) has an open issue for exactly this: a color token that only stores a hex string no longer parses as valid DTCG 2025.10, because the new spec expects the structured object form. If you maintain a tool that reads or writes token files, or you hand-authored a tokens.json file for your AI builder, this is the line that will trip you. ## Why this matters more now than it would have a year ago Design tokens used to be a designer-to-developer handoff problem. Now they're a designer-to-AI handoff problem too. Claude, Lovable, v0, Cursor, and Bolt all do a better job when you feed them a real token file instead of a paragraph describing your brand. A token file that's quietly non-compliant with the current spec is one that a stricter parser, or a future version of your builder's importer, will start rejecting. - Theming and multi-brand support, so light/dark and brand variants don't need duplicate files. - Token relationships: aliases and component-level references instead of copy-pasted values. - Wide-gamut color (Display P3, Oklch, the full CSS Color Module 4 space), which is the piece that forced the value format to change. ## What doesn't change Your CSS is fine. `#4f9bf5` still works everywhere it always did, in a stylesheet, a Tailwind config, a Figma fill. This is specifically about the interchange file, the JSON that's supposed to be the portable, tool-agnostic source of truth. If nothing reads or writes that file directly, 2025.10 changes nothing about your day. It matters the moment you, or your AI builder, or a design tool, tries to round-trip a token file through a spec-compliant parser. ## What to actually do about it You don't need to hand-edit a token file to fix this. The practical move is to stop hand-authoring tokens at all and instead extract them, either from your own live site or from a reference you're rebuilding, straight into current DTCG format. That sidesteps the whole hex-vs-object question because the export does it correctly by construction. If you already have an older token file lying around, treat it the same way you'd treat a deprecated API: regenerate it rather than patch the color values by hand. This is also a decent moment to sanity-check whatever your AI builder is actually consuming. A prose brief ("our primary is a mid blue") never breaks, because there's nothing to validate. A token file can, silently, and the failure mode is usually a build that half-works: some colors resolve, the ones expressed as bare hex don't, and you spend an afternoon debugging a theme instead of a spec compliance issue. ## Who's actually exporting to 2025.10 right now A handful of extractors already export W3C-format tokens from a live URL. Here's how they compare on the color-format question specifically: - [designlang](https://www.designlang.app/): Open-source CLI plus MCP server for Claude Code, Cursor, and Windsurf. Emits DTCG tokens (primitive, semantic, composite) plus Tailwind, Figma variables, and native iOS/Android/Flutter output. - [Design Extractor](https://www.everydev.ai/tools/design-extractor): Crawls a URL into a DESIGN.md built for AI coding agents, with a dedicated W3C Design Tokens (DTCG) export alongside Tailwind v4 and CSS variables. - [WAALEE](https://waalee.ai/): Reads the rendered DOM of any URL and exports W3C-compliant tokens plus AI-ready prompts for Claude, Lovable, v0, Cursor, and Bolt, with a WCAG contrast pass built in. No install. The honest read: the spec going stable is good news, it means the format finally has a floor everyone can build against. But "W3C tokens" as a label is about to mean something more specific than it used to. Before you drop a token file into your next AI build, it's worth checking that whatever produced it actually speaks 2025.10, not the looser draft everyone was improvising against for the last two years. --- # How to extract a full design system from any website in 60 seconds > Point at a URL, get colors, type, spacing, components, and AI-ready prompts. Here's exactly what happens under the hood. Source: https://waalee.ai/blog/extract-a-design-system-in-60-seconds Published: 2026-07-02 · 4 min read · By Kiana Bluecher and The WAALEE Team Topics: extract design system from website, design token extractor, copy website design, AI-ready design prompts, WAALEE vs dembrandt Most "design inspiration" dies in a screenshots folder. You save a site you love, then rebuild it from memory and end up with something that feels 70% right. The gap is the details — the exact greys, the type scale, the spacing rhythm — and those are the things a screenshot can't hand you. ## We read the rendered page, not the source When you paste a URL, we load it in a real headless Chromium and read the computed styles off the live DOM — the actual rendered look and feel, after CSS, fonts, and layout have all resolved. That's very different from scraping HTML. You get the values the browser actually painted. ## What you get back - A full color palette — primary, accent, neutral, and semantic — de-duplicated and organized. - Typography: families, weights, sizes, and line-heights, grouped by role. - A spacing scale and the component patterns the site leans on. - W3C-compliant design tokens you can drop straight into a codebase. - AI-ready prompts calibrated to the reference, for Claude, Lovable, v0, or Cursor. The whole thing takes a few seconds on a warm run. No signup, no browser extension — just a URL and a style guide on the other side. ## How WAALEE compares to other extractors We're not the only way to pull a design system off a page. Here's an honest map of the landscape and where WAALEE fits — cross-check any of them: - [Dembrandt](https://www.dembrandt.com/): One-command CLI that runs a headless browser and returns real computed values. Great for terminal workflows; no prompts or accessibility check. - [UIScanner](https://uiscanner.com/): Paste a URL, get tokens plus a build prompt. Closest in spirit to WAALEE; WAALEE adds W3C token export and a WCAG contrast pass. - [extract-design-system](https://github.com/arvindrk/extract-design-system): Open-source CLI and Claude/Cursor skill; outputs JSON and CSS variables for local projects. - [Design System Extractor](https://chromewebstore.google.com/detail/design-system-extractor/nnjekphemngphnhkacefcnobblojapgc): Chrome extension that reads on-page styles one page at a time. Handy for quick spot-checks. - [WAALEE](https://waalee.ai/): Web-based, reads the rendered DOM, and hands back colors, type, spacing, W3C tokens and AI-ready prompts tuned for Claude, Lovable, v0, Cursor and Bolt — plus a WCAG check. No install. The honest takeaway: if you live in a terminal, a CLI like [Dembrandt](https://www.dembrandt.com/) is a fine fit. If you want tokens and a builder-ready prompt from one paste in the browser, that's what we built [WAALEE](https://waalee.ai/) for. --- # Vibe coding is great — until it needs to look designed > AI builders ship working UIs fast. Making them look intentional is a different skill. Here's the bridge. Source: https://waalee.ai/blog/vibe-coding-until-it-needs-to-look-designed Published: 2026-06-28 · 3 min read · By Kiana Bluecher Lovable, v0, Bolt, and Claude will give you a working app in an afternoon. What they won't reliably give you is taste. The default output has a recognizable look: safe spacing, stock component styling, a palette that's technically fine and completely forgettable. ## Generic is a tokens problem The reason AI output looks generic is that the model has no opinion about your brand. It's optimizing for "correct," not "considered." Give it a concrete design system — real colors, a real type scale, real component rules — and the same model produces something that looks like a decision was made. ## Borrow a system, then make it yours Find three sites whose feel you admire, extract their systems, and use them as constraints — not to clone, but to raise the floor. Your AI builder stops guessing and starts building inside a coherent look. --- # Design tokens, explained: the language your AI actually understands > Colors and fonts are the obvious part. The real power is naming decisions so a machine can apply them consistently. Source: https://waalee.ai/blog/design-tokens-explained Published: 2026-06-24 · 5 min read · By The WAALEE Team A design token is a named design decision. Instead of "#4f9bf5", you have "color.accent.default." Instead of "16px," you have "space.4." That indirection sounds bureaucratic until you realize it's exactly what lets a tool — or a model — apply a decision the same way in a hundred places. ## Why tokens beat a palette A raw palette tells you which colors exist. Tokens tell you what they're for. "Accent" vs "destructive" vs "muted-foreground" carry intent, and intent is what an AI needs to place a color correctly instead of just using something that's roughly the right hue. ## The W3C format matters The W3C Design Tokens spec gives everyone — Figma, your codebase, your AI builder — a shared file format. When we export tokens, they're in that format, so they're portable across your whole stack instead of trapped in one tool. --- # From screenshot to style guide: reverse-engineering great design > A practical look at how to deconstruct a site you admire into a system you can actually build with. Source: https://waalee.ai/blog/screenshot-to-style-guide Published: 2026-06-20 · 4 min read · By Kiana Bluecher Designers have always learned by copying — tracing type, matching colors, rebuilding layouts. The internet just made the reference material infinite. The skill now is deconstruction: turning a finished page back into the decisions that produced it. ## Start with hierarchy, not pixels Before you pull a single hex code, name what the page is doing: what's primary, what's secondary, where the eye goes first, how sections breathe. A system that captures hierarchy transfers to your content. A system that only captures colors doesn't. ## Then extract the specifics Now get the exact values — the type scale, the spacing rhythm, the border radii, the shadow language. This is the part that's tedious by hand and instant when you read it off the rendered DOM. Pair the two and you have a style guide, not a mood board. --- # Why your AI-generated site looks generic (and how to fix it) > Five tells of default AI design — and the one input that removes all of them at once. Source: https://waalee.ai/blog/why-your-ai-site-looks-generic Published: 2026-06-16 · 3 min read · By The WAALEE Team You can usually spot an un-directed AI build in a second. Here's the checklist, and the fix. ## The five tells - A blue-ish primary that no one chose. - Even, unconsidered spacing — everything 16 or 24, nothing intentional. - One weight of one font doing all the work. - Card-on-grey layouts with no point of view. - Rounded-everything with a soft shadow, aka the default component kit. ## The one fix Feed the model a real design system before it writes a line. Extracted tokens replace every default above with a decision — a chosen accent, a real type scale, a spacing rhythm, component rules. Same builder, completely different result. --- # The anatomy of a $100M landing page > What the best-funded startups actually do above the fold — and how to lift the pattern, not the pixels. Source: https://waalee.ai/blog/anatomy-of-a-100m-landing-page Published: 2026-06-12 · 6 min read · By Kiana Bluecher and The WAALEE Team Great landing pages rhyme. Not because everyone copies each other, but because the constraints are the same: earn attention in one screen, make one promise, remove one point of friction. Study enough of them and the structure becomes obvious. ## The recurring skeleton - A specific promise in the headline — outcome, not feature. - A single primary action, repeated, never competing with a second. - Proof close to the ask: logos, numbers, a recognizable name. - Restraint in color — one accent doing real work, everything else neutral. ## Lift the system, not the screenshot The move isn't to clone a page — it's to extract the system underneath (type scale, spacing, the disciplined palette) and apply it to your own promise. That's how you get the polish without the plagiarism. --- # Colors, type, spacing: what to actually steal from sites you admire > A short field guide to the three things worth extracting — and the things that don't transfer. Source: https://waalee.ai/blog/what-to-steal-colors-type-spacing Published: 2026-06-08 · 4 min read · By The WAALEE Team "Good artists copy, great artists steal." The trick is knowing what's worth stealing. Some things transfer cleanly between brands; some don't. ## Steal these - The type scale — the ratio between sizes is brand-agnostic and instantly upgrades hierarchy. - The spacing rhythm — consistent, intentional spacing reads as "designed" more than any single element. - The restraint — how few colors and weights the site gets away with. ## Leave these Don't lift the exact palette or the literal layout — those belong to the other brand and will always look borrowed. Extract the system, apply your own content and color story, and it becomes yours. --- # How to rebuild any site 1:1 with Claude, Lovable, or v0 > A repeatable workflow: extract, hand the tokens to your builder, and reconstruct the exact look and feel. Source: https://waalee.ai/blog/rebuild-any-site-with-ai Published: 2026-06-04 · 5 min read · By Kiana Bluecher Topics: rebuild website with AI, clone site design, Lovable v0 Cursor tokens, AI website design system Rebuilding a reference by eye is slow and lossy. Rebuilding it from its own extracted system is fast and faithful. Here's the loop we use. ## The workflow - Extract the reference — colors, type, spacing, components, and W3C tokens. - Drop the tokens into your stack (Tailwind config, CSS variables, or a theme file). - Hand your AI builder the tokens plus the generated prompt, and rebuild section by section. - Prefer the raw tokens over the prose brief for anything precise. ## Same look, your content Because the system is explicit, the model stops guessing brand colors and starts matching them verbatim. You reconstruct the exact feel, then swap in your own words and imagery. That's a rebuild, not a re-imagining. ## The AI builders this works with The extracted tokens and prompt drop straight into whichever builder you use: - [Lovable](https://lovable.dev/): Full-stack app generation, tuned for UX. Paste the prompt to reskin the whole build. - [v0 by Vercel](https://v0.app/): Strong at frontend UI components; feed it the tokens for on-brand output. - [Cursor](https://cursor.com/): Precision edits in a real IDE — best for applying tokens across a larger codebase. - [Bolt.new](https://bolt.new/): In-browser full-stack builds; hand it the token bundle plus the brief. - [Claude](https://claude.ai/): General-purpose; great for section-by-section restyles from the raw tokens. --- # W3C design tokens: exporting a system your whole team can use > One portable file that Figma, your codebase, and your AI builder all understand. Source: https://waalee.ai/blog/w3c-design-tokens-for-your-team Published: 2026-05-30 · 4 min read · By The WAALEE Team The dream of a single source of truth for design usually breaks on file formats. Design lives in Figma, code lives in the repo, and the two drift. The W3C Design Tokens format is the boring standard that finally closes the gap. ## Why standardize When your tokens are in a shared format, a color change flows from one file to design, to code, and to whatever your AI builder generates next. No re-keying, no drift, no "which grey is correct" debates. ## Export, don't re-author Instead of hand-writing a token file, extract it from a real reference (or your own current site) and export straight to W3C JSON. You get a starting system in seconds and refine from there. --- # Turning inspiration into production: a practical workflow > The end-to-end path from "I love this site" to shipped, on-brand code — without the guesswork. Source: https://waalee.ai/blog/turning-inspiration-into-production Published: 2026-05-26 · 5 min read · By Kiana Bluecher and The WAALEE Team Inspiration is cheap; execution is where projects stall. The distance between a reference you love and a page you ship is usually a pile of small, undocumented decisions. Here's how to collapse it. ## The path - Collect 2–3 references whose feel matches your goal. - Extract each into a system and compare — the overlap is your direction. - Assemble a working set of tokens: palette, type scale, spacing, components. - Generate prompts and rebuild with your AI tool, section by section. - Export the tokens so the next page starts from the same source of truth. ## Ship, then compound The first page is the expensive one. Once your system is captured, every page after it inherits the same look for free — which is exactly how brands stay consistent as they scale.