Cursor is very good at writing a component and has no idea whether your project already has one. That gap is the whole problem with agent-written interfaces in an existing codebase: the output is fine and it is the fourth version of something you already own.
Three mechanisms close it, and they stack.
Rules
Cursor reads project rules, and this is the cheapest lever available. A short file that says where components live, which primitives to prefer, what the token names are, and that existing components should be searched before new ones are written.
Keep it specific and short. "Use our design system" is not a rule; "UI primitives live in components/ui, colours come from CSS variables listed in globals.css, never hardcode a Tailwind colour" is. Rules that describe the codebase are followed; rules that describe aspirations are ignored.
MCP
Rules tell the agent what to prefer. MCP gives it something to fetch. The 21st MCP adds a search tool over the catalogue and an install tool, so instead of writing a hero the agent can find four, show them as previews, and install the one you pick with the shadcn CLI.
The MCP guide covers what changes when a catalogue exists: the component is real code with a declared dependency list, you see it before it lands, and pointing the same mechanism at a private registry makes it install your components rather than new ones.
Prompting
The pattern that produces usable output is the same in any editor, and it is mostly about constraints.
Name the section and the constraint together, because the constraint is what makes one result better than another. Say what it must not do - no animation library, works as a server component - since those two eliminate most of a catalogue and neither can be inferred. Ask for options before code. And give it the token names, so adaptation happens in the same step rather than in a second pass.
One more that is specific to an existing codebase: tell it to look first. "Check components/ui for an existing dialog before writing one" is one sentence and it prevents the most expensive failure mode.
What to check afterwards
Agent output has a consistent set of gaps, and they are the same for a component it wrote and one it installed: a missing focus-visible state, an animation with no reduced-motion branch, a dark mode that was generated rather than designed, and text that only exists after hydration. The review checklist is the full pass.
The judgement calls stay yours too. Whether that dialog should be a page, whether the carousel should be a list, whether the empty state needed an example. A catalogue answers what exists; it does not answer what the screen should be.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| Cursor rules | Telling the agent your conventions, for free | Instructions, not components |
| 21st MCP | Search and install with previews inside the editor | Installs need a membership |
| A team registry | The agent reusing your components | Somebody has to publish them |
| The shadcn CLI by hand | Full control over what gets installed | You do the searching |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- What should Cursor rules say about UI?
- Where components live, which primitives to prefer, what the token names are, and that existing components are searched before new ones are written. Be specific: use our design system is not a rule, while UI primitives live in components/ui and colours come from the CSS variables in globals.css is.
- Do rules replace an MCP catalogue?
- No, they stack. Rules tell the agent what to prefer; MCP gives it something to fetch. With a catalogue connected, the agent can find four heroes, show them as previews and install the chosen one through the shadcn CLI instead of writing a fifth from memory.
- How do you prompt Cursor for a component?
- Name the section and the constraint together, say what it must not do, ask for options before code, and give it your token names. In an existing codebase add one more line: check the components folder for an existing version before writing one.
- What should you check in agent-written UI?
- Whether the text exists in the HTML before hydration, whether Tab reaches everything with a visible focus indicator, whether the states beyond the happy path exist, and whether it hardcoded a colour instead of reading a token. Those four catch most of what reaches production.