How to Make Cursor Follow Your Design System

Cursor follows the context it can find

Cursor is good at reading and changing code. It does not automatically know which parts of a repository express the product’s current design language. If several buttons, token files, or page patterns exist, the agent has to infer which one is canonical. That local guess creates AI-generated UI drift, even when the generated code is technically correct.

Cursor’s current rules system is designed to reduce this ambiguity. Project rules live in .cursor/rules as version-controlled .mdc files. A rule can always apply, attach to matching files, load when the agent considers it relevant, or be invoked manually. Cursor also reads AGENTS.md as a simpler Markdown instruction source.

The important part is not creating many rules. It is giving each rule a precise job.

Keep design decisions in their executable form

Colors, typography, spacing, and motion should exist as semantic tokens in CSS, a theme file, or a token package. Components should exist at stable import paths and include their real states. Product patterns should be documented with approved examples. A short DESIGN.md can explain how these parts fit together.

The Cursor rule then acts as a pointer. For UI files, it can require the agent to read DESIGN.md, use semantic tokens instead of raw values, and search the canonical component directory before creating a new primitive. Because the rule can reference files, there is no need to duplicate the full palette or component API inside the rule itself.

This separation matters. When a token changes, the agent still reads the current token source. When a component gains a loading state, the component remains the authority. The rule stays short and stable.

---
description: Product UI rules
globs: "src/**/*.{tsx,css}"
alwaysApply: false
---
Read DESIGN.md before editing UI.
Use semantic tokens from src/styles/tokens.css.
Reuse components from src/components/ui before creating a new primitive.

Test the system with a real product task

Do not validate the setup by asking Cursor to generate an isolated button. Give it a normal feature: add a settings section, extend a table, or design an empty state. Then inspect whether it found the existing components, used allowed variants, handled responsive and error states, and avoided raw values.

If the output drifts, the cause is usually visible. The rule may not match the edited files. The component path may be unclear. The token names may describe appearance rather than purpose. Or the repository may contain several competing patterns. Fix the source before adding more prose.

Cursor’s visual editing and design integrations can help inspect and refine a live interface. They still depend on a maintained system. A visual editor can adjust a value; it cannot decide whether that value should become a reusable product rule.

Know when configuration will only preserve the mess

For a small product with a few consistent screens, writing the token source, component map, and Cursor rule may be enough. For a larger product with duplicated components and conflicting flows, the same configuration can make the wrong patterns easier to repeat.

That is the point for a SaaS UX audit. First decide what is canonical. Then encode it for Cursor. The same source can also support Claude Code and Lovable, so the product does not fork when the build tool changes.