Agent-ready design system for your product
An agent-ready design system is a design system that lives in the code as tokens, components and written rules, so Claude Code, Codex, Cursor and other coding agents build new screens from it instead of guessing.
| Contains | Tokens, themed components, agent rules and checks, in the repository |
|---|---|
| Works with | An existing codebase, including a design system already in it |
| Theming | Colour, type, radius and density switchable from tokens |
| Agents | Rule files for Claude Code, Codex and Cursor |
| Useful for | Product teams that build with AI coding agents |
Why coding agents drift off-brand
A coding agent writes a new screen in minutes. It does not know which blue is the primary colour, which spacing step the cards use, or that a table component already exists. So it guesses, and every guess is a small inconsistency that someone has to find and fix later.
The usual answer is a style guide or a Figma library. Neither helps here. An agent does not open Figma, and it does not remember a style guide from one session to the next. It reads the repository. Design decisions that are not in the repository, in a form the agent can follow, do not exist for it.
What it is made of
Tokens. Colour, type, spacing, radius and motion as named values in one place, with a theme layer on top. Changing the brand colour or the density of the interface means changing a few tokens, not searching through hundreds of files.
Components built on the tokens. The components a product uses most are built on those tokens, so no component carries colours or sizes of its own.
Rules for agents. Plain text files in the repository (AGENTS.md, CLAUDE.md, Cursor rules) that say which tokens and components exist, when to use which, and what never to do. Each rule is written so it can be checked, not as a matter of taste.
Checks. Small scripts that catch what slips through anyway: a raw colour where a token belongs, a new component that repeats one already in the library. They run before a commit, so drift is caught where it starts.
It starts from what already exists
Most products already have a design system of some kind, even if nobody calls it that: a colour file, a set of components, a few conventions the team remembers. Nothing has to be thrown away for the new system to stand. What exists gets named, tidied and written down, so an agent can read it.
Where there is no system at all, the foundation comes from the product as it is today, so the first version already matches what users see.
How it works
1. Check
It starts with a look at the repository: which design decisions already live in code, which live only in people's heads, and what the agents get wrong most often.
2. Foundation
Tokens and the theme layer go in first, mapped from the values the product already uses. Nothing changes visually at this step. The same interface now comes from named decisions.
3. Components
The most used components move onto the tokens one by one, and the screens that use them are checked after each move.
4. Agent rules
Rule files and checks are added and tried with the agents the team uses. A new screen is built from a prompt, and whatever comes out off-brand becomes a new rule or a new check.
In short
A coding agent follows what is in the repository, nothing else. An agent-ready design system puts the design decisions there, as tokens, components and rules that can be checked. It starts from what the product already has, and every mistake an agent makes becomes one more rule or check.
Last updated