Where do Cursor project rules live?

In .cursor/rules, as .mdc files that are version-controlled with your project.

Which rule type should a design system use?

A short Always Apply rule for the non-negotiables, pointing to fuller files the agent reads when it builds UI; Cursor also offers rules applied intelligently, to specific files, or manually by @-mention.

Should I paste my whole design system into one rule?

No. An always-on rule is sent with every chat, so keep it to a few lines and reference tokens.json and rules.md by path.

Can I use a Livery kit in Cursor?

Yes. Unzip the kit into your project and add a one-line rule that points to it; the kit's SKILL.md holds the step-by-step process.

Cursor Rules for Design: Make AI-Built UIs Look On-Brand

By @andymarrows · Updated 2026-10-25 · 6 min read

The short answer

Put your design in Cursor's project rules (an .mdc file in .cursor/rules) as a short, always-on rule that points to fuller files: design tokens in JSON, a rules document with principles and a Never list, and component recipes. Keep the always-on rule brief, reference the detail by path, and ask the agent to apply changes one area at a time.

Where design rules go in Cursor

Cursor reads project rules from .cursor/rules. Each rule is an .mdc file (Markdown with a short header) that can be always applied, attached to matching files, or pulled in when the agent decides it's relevant. For design, two layers work best:

An always-on rule of a few lines: the non-negotiables (palette roles, the type scale, one accent, no gradients) and where the full system lives.
Reference files the rule points to: tokens.json, rules.md, components.md. The agent reads them when it's building UI, not on every request.

.cursor/rules/design.mdc

---
description: Our design system
alwaysApply: true
---

Always follow the design system in .livery/my-site/.
- Colours, type and spacing come from tokens.json; never hard-code values.
- One accent per screen, on the primary action.
- Read rules.md before building or restyling any UI.

Write rules with reasons

"Use #0d7268 for buttons" is followed for a while and then broken in a modal. "The accent marks the one action you want taken, so use it once per screen" survives new screens, because the agent understands the intent. Give every rule its reason, and keep a short Never list: never a gradient, never a coloured shadow, never body text under 14px.

Stop the agent from rewriting everything

Asked to "apply the design", an agent may restyle the whole app in one pass. Ask for a plan first, then one area per change: tokens first (so colours and spacing are centralised), then components, layout, motion. Review each diff on its own.

Start from a real site's design

A Livery kit is the same set of files, measured from any public website: tokens.json, rules.md, components.md, layout.md, motion.md and a SKILL.md with the step-by-step process. For Cursor, unzip it into your project and add the one-line rule above. The agent follows the same audit, ask and commit steps as in Claude Code.

Questions

Where do Cursor project rules live?: In .cursor/rules, as .mdc files that are version-controlled with your project.
Which rule type should a design system use?: A short Always Apply rule for the non-negotiables, pointing to fuller files the agent reads when it builds UI; Cursor also offers rules applied intelligently, to specific files, or manually by @-mention.
Should I paste my whole design system into one rule?: No. An always-on rule is sent with every chat, so keep it to a few lines and reference tokens.json and rules.md by path.
Can I use a Livery kit in Cursor?: Yes. Unzip the kit into your project and add a one-line rule that points to it; the kit's SKILL.md holds the step-by-step process.

Sources

Try it on a site you love

Paste a link and get an installable design kit in about a minute. Free.

Create a kit Browse kits

More guides