Claude Code design system: the 3 ways to wire one in

Search "claude code design system" and Google now answers with a product, not a method: Anthropic's Claude Design owns the top of the page. That answer is incomplete.

Quick answer: there are three ways to give Claude Code a design system, and they are not interchangeable. (1) Claude Design's design systems, synced from your repo with the /design-sync command, which Anthropic says "reads your tokens and components directly, and works best for product design systems in code." (2) A DESIGN.md file committed to the repo, which works in every Claude Code session, on every plan, with no product dependency. (3) An MCP server (Figma, Storybook) that serves live components on request. Pick by where your design truth lives: in code, in a file, or in a design tool.

What changed in 2026

Until this spring, giving Claude Code a design system meant writing context files by hand. Then on 17 April 2026 Anthropic shipped Claude Design, "a new Anthropic Labs product that lets you collaborate with Claude to create polished visual work like designs, prototypes, slides, one-pagers, and more," in research preview for Pro, Max, Team, and Enterprise subscribers.

The feature that matters for this query is not the canvas. It is the design system store underneath it. From the launch post: "During onboarding, Claude builds a design system for your team by reading your codebase and design files. Every project after that uses your colors, typography, and components automatically."

That store is now wired into Claude Code directly, which is why the old hand-written-context answer and the new product answer both exist at once. The rest of this post is how to choose between them.

Route 1: Claude Design's design systems and /design-sync

Anthropic's support documentation lists three ways to create a design system, and one of them starts in your terminal:

1. From chat: "Ask Claude to build a design system from your connected apps, uploaded files, Figma files, decks, logos, and fonts."
2. From Claude Code: run /design-sync in the repo. Per the same doc, it "reads your tokens and components directly, and works best for product design systems in code."
3. From claude.ai/design: manual setup in the standalone workspace.

What you get is a stored artifact containing, in Anthropic's words, your "Color palette: Primary, secondary, and accent colors," "Typography: Font families, sizes, and weights," "Components: Buttons, cards, navigation elements," and "Layout patterns: Spacing, grid systems, and page structures." Design systems become "artifacts Claude can use in any chat, including in Claude Code," managed under Settings, then Customize, then Design systems.

Two constraints to know before you choose this route:

• Plan gating. "Design systems are available in beta on Pro, Max, Team, and Enterprise plans. They're on by default on Pro, Max, and Team plans." No free tier, and the feature is beta inside a research-preview product.
• Source preference. Anthropic's own product page says creating one via Claude Code "works best for organizations with existing React design systems." If your components are not in code yet, the sync has less to read.

Route 2: A DESIGN.md in the repo

The second route predates Claude Design and survives it: commit a markdown file that states your tokens, type scale, spacing, and component rules, and let Claude Code read it like any other context file. We have documented this workflow in give your AI agent a design system and the format itself in what is a DESIGN.md file.

What is new is that the Claude Design launch turned this file format into an ecosystem. The number 2 organic result for this query is VoltAgent/awesome-claude-design, a GitHub repo at 4.2k stars offering "68 ready-to-use design system inspirations in DESIGN.md format" across 11 categories, from AI platforms to fintech. Its own instructions bridge the two routes: upload a DESIGN.md at claude.ai/design under "Create new design system," then "Add assets," or attach it in chat and ask Claude to "Create a design system from this DESIGN.md."

The community is converging on the same file. In the r/ClaudeDesign thread "Need suggestion on Design Systems" that ranks on this query, the top visible reply in Google's snippet reads: "I built a Claude Code plugin that extracts any website's full design system ... DESIGN.md prompts by aesthetic families for Claude Design."

Why keep a file when the product exists? Because the file is portable and the product is not. A DESIGN.md works on the free tier, works in Cursor and Codex and every other agent, works offline in CI, and version-controls with the code it governs. Claude Design's store is a better extractor; the file is a better contract.

Route 3: An MCP server for live components

The third route is for teams whose design truth lives in a tool, not in the repo. The Figma MCP server lets Claude Code query real design data at generation time. Builder.io's guide for designers describes the effect: "Claude will pull the structured design data from Figma, see your spacing/tokens/components, and generate code that actually fits your system."

Storybook ships an MCP addon that serves your actual component inventory, and the design system platforms (zeroheight, Knapsack, Supernova) have their own servers. We mapped that landscape, including what none of these servers can do, in design system MCP.

MCP is the only route that stays current automatically: change a token in Figma and the next query sees it. The cost is setup, auth, and the fact that an answer-on-request server never tells the agent what to do on a screen you have no component for yet.

Which route when

✅ Use /design-sync (Route 1) when your design system already lives in code, your team is on Pro, Max, Team, or Enterprise, and you want the same system available in Claude Design's canvas and in Claude Code without maintaining a file.

✅ Use a DESIGN.md (Route 2) when you need portability across agents and plans, when the design system should be reviewed in pull requests like code, or when you are starting from someone else's system rather than extracting your own.

✅ Use MCP (Route 3) when the source of truth is Figma or Storybook and it changes faster than anyone would update a file.

❌ Don't rely on Route 1 alone if anyone on the team uses other agents. The synced artifact lives in Claude's settings, not in your repo.

❌ Don't rely on Route 3 alone for style governance. A component server answers "what buttons exist," not "what should a new screen look like."

❌ Don't skip all three and prompt style ad hoc. That is how every screen converges on the same generic look, a failure mode we documented in why AI-generated apps look the same.

The routes also stack. The pattern we see working: a DESIGN.md as the committed contract, /design-sync to mirror it into Claude Design for visual exploration, and MCP where live component data earns its setup cost.

The workflow: start from a real system

Whichever route you pick, it needs a source design system worth syncing. If you do not have one yet, do not make the agent invent one.

1. Browse the duply library and pick a product whose design fits what you are building. Each entry documents a real product's tokens, type scale, and component rules.
2. Copy its DESIGN.md from the entry page, for example Linear's DESIGN.md, into your repo.
3. Point your route at it: reference it in CLAUDE.md for Route 2, or create a Claude Design system from it per the VoltAgent instructions above for Route 1.
4. Keep the agent honest: the full loop is in give your AI agent a design system.

FAQ

Is there a Claude design system template? Yes, two public sources. VoltAgent/awesome-claude-design offers 68 DESIGN.md files across 11 categories, and the duply library documents real products' design systems in the same agent-readable format, each downloadable from its entry page.

Where can I download a design system for Claude? From a DESIGN.md catalog. Every duply library entry has a design-md page (for example /linear/design-md) you can copy directly into a repo or upload to Claude Design as an asset.

Do Claude design systems work on the free plan? No. Per Anthropic's support docs, "Design systems are available in beta on Pro, Max, Team, and Enterprise plans." A DESIGN.md file in the repo works on any plan, because it is ordinary context.

What does /design-sync actually read? Anthropic says it "reads your tokens and components directly, and works best for product design systems in code," and the product page narrows that further to "organizations with existing React design systems." It extracts colors, typography, components, and layout patterns into a stored design system.

Is /design the same thing as a design system? No. /design is Claude Code's artboard skill, shipped in research preview in August 2026: Claude publishes editable artboards, you pick one, Claude implements it. A design system is the stored style contract those artboards should follow. We compared /design against the other options in Claude Code design skills.

Claude Design or Claude Code for design system work? They split by medium. MindStudio's comparison puts it plainly: "Claude Design is a visual, browser-based tool built for iteration without writing code. Claude Code is a terminal-based agentic coding" tool. The design system store is shared between them, which is the point of /design-sync.

Does a synced design system stop style drift? It reduces it, but extraction is description, not law. Anthropic's docs describe Claude checking output against the active design system, and UX Planet's hands-on test found the value is that generations "use styles, components and interaction patterns from your design system." For screens outside the system's coverage you still need stated rules, which is what a DESIGN.md adds over raw tokens.

Summary

• "Claude code design system" now has a product answer (Claude Design) and a method answer (DESIGN.md, MCP), and most pages on the SERP only give you the product one.
• Route 1: /design-sync extracts tokens and components from code into Claude Design's store. Beta, paid plans only, strongest with React systems.
• Route 2: a DESIGN.md in the repo is portable across agents and plans, and reviews like code. 68 public examples sit in a 4.2k-star GitHub repo; duply's library adds real-product systems.
• Route 3: MCP servers (Figma, Storybook) serve live components but set no rules.
• The routes stack: file as contract, sync for the canvas, MCP for live data.

Start from a real system instead of a generated guess: browse the duply library, copy a DESIGN.md, and wire it in with whichever route fits your stack.

Related reading

• Give your AI agent a design system
• What is a DESIGN.md file?
• Design system MCP: what it is, who has one, what it can't do