Devs who used to avoid frontend now ship full UIs. AI teams spin up proofs of concept in an afternoon. Even non-engineers generate HTML pages to share ideas.
Everyone builds UI now. That's a good thing. More people building means more ideas get tested.
But there's a catch. Most of it doesn't look like the product. Different colors, random fonts, default component library styles, five apps that should feel like one.
Here's how one team went from a CSS question to a one-command skill.
"Ask whoever owns the design system first" doesn't scale
The obvious fix is a process one: if you're building UI, ask whoever owns the design system first.
It rarely works. Asking a person means waiting. Generating a screen takes seconds. When the fastest path skips the review, people take the fastest path. They're not wrong to.
The problem isn't discipline. It's that the design system lives in a place the agent can't reach.
"Can you send me the CSS?"
Then the request shows up. A developer is building a prototype and wants it to match the product as closely as possible. Is there a CSS file? A folder? A zip?
That question sounds simple. It isn't.
There is no single CSS file. The look of a product lives in a theme, design tokens, a font, an app shell with specific measurements, and a set of rules nobody wrote down. And the person asking isn't going to apply any of it by hand. The agent is.
Just handing the agent your docs isn't enough either. Docs describe the system. They don't make decisions or set a quality bar.
So the real question becomes: how do you hand a design system to an agent?
The design system becomes a skill
A skill is a packaged set of instructions an agent can pick up when a task calls for it. Install it once, and any agent in the project builds with the product's look, in whatever stack it's working in.
This one was built with Cursor's create-skill, using a detailed prompt about exactly how it should behave. The decisions that mattered most:
- Only on request. Skills can load on their own when a task looks relevant. This one doesn't. It runs only when someone explicitly invokes it, so it never restyles a UI on its own.
- One command, no menus. No subcommands. No "which stack are you using?" The skill detects the stack itself.
- Production code is the source of truth. The look is extracted from the real repo. Never invent a hex value or a font. If something is missing, ask.
- Strict on tokens, flexible on mapping. Colors and type are not negotiable. How they map into each component library is up to the agent.
- Adapters for the stacks people actually use. Not just React libraries. Angular, vanilla HTML, Python UIs like Gradio and Streamlit, terminal apps with Rich or Textual, plus fallbacks when nothing matches. That's what non-frontend teams build with.
- A quality floor. A short checklist the agent loads right before touching UI.
- A bounded loop. Apply, verify once, one round of fixes, stop. No endless redesign.
The quality floor matters more than it looks. Agents make things look finished really fast. Rounded corners, a soft shadow, and it feels ready. But built isn't done, and done isn't good. The checklist is there so "it renders" doesn't get confused with "it's right."
It started as a personal skill in ~/.cursor/skills/. Then it moved to a shared, internal repo, installed per project:
npx skills add your-org/your-skills-repo
One command. Nothing to copy. No prompt to find.
Note: the actual skill is internal, so it isn't shared here. An open version you can point at your own design system is in the works.
What actually changed
The interesting part isn't the skill. It's the role.
The design engineer stops being a bottleneck and starts being a distributor. Not building every screen, but packaging judgment so it shows up wherever someone builds.
And the system itself changes too. A design system used to scale consistency: same button, same color, everywhere. Now it has to scale intent. Not just what the product looks like, but why, written down clearly enough that an agent can follow it without a designer in the room.
If you're trying something similar:
- Start from production code. Not a Figma file, not memory. Agents copy whatever you give them, mistakes included.
- Meet people in their stack. The people generating UI aren't all frontend devs. If it only works in one framework, it won't get used.
- Leave rules behind. A one-time restyle fades after a few prompts. Rules in the project keep it consistent.
Design systems used to be documentation for humans. Now they're also instructions for agents.
The agent can build the screen. It can't decide what the product should feel like. That part still needs someone to ship it.
How is your team handling this? Are agents following your design system, or inventing their own?
Top comments (0)