How to give Claude Code or Cursor a design system to follow
A coding agent will follow a design system if you put one where it can read it. What to write, where to put it, and the rules that stop it inventing its own styles.
A coding agent like Claude Code or Cursor is good at following instructions it can find. Most “the AI ruined my styling” stories come down to one thing: the design system existed in someone's head, or in a design file, and not in the project where the agent could read it.
Here is how to put it there.
What an agent needs
A design system for an agent has three parts. None of them is large.
Named values. Every colour, text size, space and corner size your app uses, each with a name. In a project that uses Tailwind, this is your theme: a short list of CSS variables. If a value has no name, the agent should not be using it.
Finished parts. The real code for your buttons, form fields, menus, dialogs and tables, in a folder of their own. Each part should already handle its states: hover, focus, pressed, disabled, and dark mode.
Rules. A short page of instructions that says how the first two are to be used.
Where to put the rules
Both tools read instruction files from your project.
- Claude Code reads a file called
CLAUDE.mdat the top of your project at the start of every session. - Cursor reads project rules, kept in a
.cursor/rulesfolder.
Keep the rules short. A long document gets skimmed, by agents as much as by people. If you have a lot to say about one part, put it in a note next to that part and have the rules file point to it.
Rules that work
These are the ones that make the most difference. Adapt the wording, keep the firmness.
- Use the ready part. “If a component exists in the components folder, use it. Do not write a new button, input or menu.”
- No invented values. “Never write a raw colour or pixel size. Use the theme's names. If none fits, stop and ask.”
- Say when something is missing. “If the design system has no part for what I asked, tell me. Do not create a substitute without saying so.”
- Do not restyle. “Do not change fonts, colours or spacing to make a page look more distinctive.”
- Check before finishing. “Before you say you are done, look at the screen you built and compare it with an existing one. List anything that does not match.”
Rule three matters more than it looks. Without it, an agent that hits a gap will quietly fill it with something of its own, and you will not notice until the app has three kinds of dropdown.
Tell it what pages look like
Parts are not enough. An agent also needs to know how they go together. Describe your page types once: a list page has a title bar, filters, then the list. A settings page has sections with a heading and rows. With that written down, a new screen starts from a layout that already works, instead of from a blank page.
A quick test
Open a fresh session and ask for a page you have not built yet. Then look for three things:
- Did it use your parts, or write new ones?
- Is there any colour or size in the code that is not one of your names?
- Did it tell you about anything it could not do?
If any answer is wrong, the fix is nearly always in the rules file, not in the request.
If you would rather not build this yourself
Making the parts is the slow bit: dozens of components, each with every state. Goop is that work done for you, with React and Tailwind source that lives in your project and the guide your agent follows. It is not out yet. You can leave your email to hear when it is.