Turning a Design System into a Claude Skill
Turning a Design System into a Claude Skill
ELI5/TLDR
Ryan Rumsey took an 11-year-old UI component library written in Sass and converted it into a Claude Skill — a set of markdown files that tell Claude not just what a button looks like, but when to use which button. He then demonstrated that Claude could generate both working HTML and a Figma-compatible JSON file from the same skill, producing consistent, responsive layouts across both tools. The pitch: this is how teams can make their existing design systems “AI-ready” for vibe coding without the model hallucinating random UI.
The Full Story
The Question Nobody Had Answered
A designer named Hang had been asking the same question for weeks in public: can anyone show real evidence of taking an existing design system and making it usable for vibe coding? Not building something new. Taking the thing that’s already there and making AI respect it. Ryan decided to try.
UI Frameworks Are Not Design Systems
Ryan draws a line most people blur. A UI framework defines structure — how a box renders at different sizes, what a button looks like in code. A design system goes further. It includes principles, governance, motion standards. It answers the question a UI framework never does:
“What are the right conditions to use a button versus a radio? When using a button, what are the right conditions to use this type of button versus another type of button?”
That governance layer — the when and why, not just the what — is exactly the part teams have always struggled to get people to follow. It is also, Ryan argues, exactly the part AI needs most.
The Conversion Process
Ryan started with a Sass-based UI framework his team built 11 years ago. Basic stuff, tokens, components. He then borrowed principles and color guidance from Microsoft’s Fluent design system to flesh it out into something closer to a real design system.
He worked with Claude to review the entire existing system, understand it, and then convert it into a series of markdown files — a Claude Skill. The result after a few hours: markdown files covering governance (how app shells should work, how empty states should behave, color usage rules), plus the component definitions themselves translated from Sass into a format Claude can follow as instructions.
The skill works as a routing system. It tells the model: when someone asks you to build something, go look at these rules, use these components, follow these principles.
MCPs vs. Skills — Different Jobs
Ryan makes an interesting architectural distinction. MCPs (Model Context Protocol servers) are great for digging into data, finding source-of-truth information, pulling things out of live systems. But design systems are not live data. They are stable governance documents that do not change day to day. A Claude Skill — essentially a structured set of markdown instructions the model reads before doing anything — fits that use case better.
The Demo
Ryan ran a live test using Claude’s co-work mode. He prompted: build me an internal communications app with channels, file sharing, an activity feed, and event RSVPs. Claude asked a few clarifying questions (default view? company type? how prominent should events be?), then went to work.
Behind the scenes, Claude read the skill files, generated a JSON file as the single source of truth, and produced both an HTML prototype and a Figma rendering from it.
The HTML version: responsive, hoverable, functional at 1440, 768, and 375px breakpoints. The Figma version, loaded via a prototype plugin Ryan built to skip the API setup: identical layout, same responsive behavior, same component usage.
“You’re probably like, ‘This is ugly.’ Yeah. Well, the ugliness is because our UI component library is super basic.”
The point was never aesthetics. The point was consistency. Both outputs followed the same rules. No hallucinated components. No rogue styling. To make it prettier, you update the rules in the skill itself, and everything downstream changes.
The Figma Bridge
Ryan prototyped a Figma plugin that reads the same JSON file Claude generates. This means a designer working in Figma and a developer vibe coding in Claude are referencing the same source of truth. The designer gets real components rendered in Figma. The developer gets HTML that follows the same governance. Neither can accidentally drift from what the design system defines.
This is the part that matters for teams. The perennial problem with design systems is adoption — people ignore the rules. If the AI enforces the rules by construction, and the Figma plugin renders from the same ruleset, drift gets harder.
Claude’s Take
This is a genuinely practical idea, and Ryan is solving a real problem. The design-system-to-AI-skill pipeline is one of those things that seems obvious in retrospect but almost nobody has demonstrated end to end.
The distinction between UI frameworks and design systems is the key insight. Most “AI + design system” demos amount to feeding Tailwind classes or component libraries into a prompt. That handles the what. Ryan’s approach encodes the when and why — the governance layer — which is where vibe coding typically falls apart. Models are perfectly happy generating a beautiful dropdown where the design system specifies a radio group. Without the decision logic, you get output that looks right but is architecturally wrong.
A few honest caveats. The demo is one person, working with a basic 11-year-old framework, on self-selected prompts. The hard test is whether this holds up when 30 different people on a team are prompting in 30 different ways, with edge cases the skill author never anticipated. Markdown governance files can get stale just like any other documentation. And the Figma plugin is a prototype — the gap between “loads a JSON file locally” and “production-ready bidirectional sync” is significant.
Still, the core thesis is sound: if you want AI to follow your design system, you need to give it the rules humans were supposed to follow but often did not, in a format optimized for how these models actually process instructions. Claude Skills — structured markdown with routing logic — are a reasonable vehicle for that. Whether this specific implementation scales to enterprise design systems with hundreds of components and dozens of teams is unproven, but the approach deserves serious testing.