Your Design System’s Got Skills?

I’ve been tinkering with something lately that I think more design system teams should pay attention to. I’m trying to teach AI how my design system works through Claude skills and Cursor rules.

The problem AI has with your design system

If you’ve used any AI coding tool to generate UI, you’ve seen this. You ask for a card component, and it gives you something that looks right but uses none of your tokens, references components that don’t exist in your library, and ignores every pattern your team spent months establishing. The output is plausible. It’s also wrong in ways that are tedious to untangle.

Your design system has opinions. It has a token taxonomy, component APIs, composition patterns, and a11y requirements. AI doesn’t know any of that. It’s working from general training data, not your system. So it gives you generic Bootstrap-flavored markup and leaves you to clean it up.

That cleanup time adds up fast, especially across a team.

Skills and rules: the 80/20 play

MCP servers for design systems are getting well-deserved attention right now and rightfully so. It’s actually where I spent time early on building and setting up to help provide context for the design system I work on. MCP is powerful, and it lets AI tools query your system’s components, tokens, and docs through a structured protocol. But it requires infrastructure. You need to build and run a server.

Claude skills and Cursor rules are the simpler path. A skill is a markdown file with instructions, reference material, and optional scripts. A Cursor rule is very similar, a text file that gives the AI context about your project’s conventions. No server, no API. Just documents that describe how your system works, loaded into context when relevant.

I’ve started investigating and building a couple of these for my own work, and the payoff has been immediate. Instead of fixing AI output that ignores my component library, the AI starts from the right place. It knows which components exist and which tokens to use by either guiding it to the proper files or providing an explanation right inside the file itself. I am still in early trials myself, and it’s not perfect, but the gap between what it generates and what I’d actually ship has gotten a lot smaller.

Types of skills your DS team could build

Out of the gate, I have been trying to come up with and define a few skills that I think could be useful.

A component usage skill is probably the highest-value starting point. Which component to reach for in common scenarios, correct props, slot patterns, and do/don’t examples from your docs. This alone changes the quality of what AI generates against your system.

A token reference seems like the natural companion. Your full taxonomy with guidance on when to use semantic vs. primitive tokens. If your system supports theming or multiple brands, this is where you encode that logic, so AI stops guessing.

An accessibility skill bakes your a11y standards into generation. ARIA patterns, keyboard navigation, focus management, contrast expectations. Catch it at the source instead of flagging it in review.

If you’ve got a legacy system and a current one (I’m dealing with this right now), a migration skill that knows both APIs and can map between them saves real time. A documentation skill keeps contributions consistent without a style guide that nobody reads. A code patterns skill captures your team’s file structure and naming conventions, the tribal knowledge that usually lives in someone’s head.

Project skills vs. personal skills

Not every skill needs to live in the repo. This is something I’ve been thinking about as I work on more of these.

Some skills belong at the project level, committed to the repo where the whole team benefits. Component usage, token reference, and a11y rules. These are the source-of-truth skills that keep everyone generating consistent, on-system code. When a new developer joins the team and starts using AI from day one, the AI already knows how your team works.

Other skills are just for you. Maybe you’ve got one for how you scaffold new components, or one that matches your PR description format, or shortcuts for tasks you repeat often, like version bump PRs. These can live in your user-level config and make you faster without imposing your preferences on anyone else.

The split matters. Project skills enforce consistency. Personal skills are about your own speed. Mixing them up creates friction, and nobody wants to inherit someone else’s personal workflow baked into the repo.

Why this matters now

Developers are already using AI to write code against your design system. That’s happening whether you’ve prepared for it or not. The question is whether the AI knows your system or is guessing.

I wrote recently about the AI productivity paradox, how AI often increases workload instead of decreasing it because you spend so much time reviewing and fixing output. Skills and rules attack that problem at the source. Give AI the right context upfront, and there’s less to fix on the other end.

We spent years meeting designers in Figma with component libraries. We met developers in their repos with npm packages. Now we need to meet them inside their AI tools. Skills and rules are how you do that without a big infrastructure investment.

What are you building?

I’m still early in this. I’ve got a few skills running that have already changed how I work, but I know there’s a lot more to figure out. Have you built Claude skills or Cursor rules for your design system? Found an approach that works well?

I’d love to hear what people are doing. If you’ve got something working, tell me about it.