Cursor writes UI fast, but without guidance it falls back on generic defaults. Cursor rules fix that. They are instructions Cursor adds to the model's context on every run, and a DESIGN.md is the best content for a design rule because it already lists your colors, type and spacing in one place.
What are Cursor rules?
Cursor rules are persistent instructions for the Agent. Project rules live in the .cursor/rules folder as .mdc files: Markdown with a small frontmatter block at the top. They sit in your repository, so the whole team gets the same rules. The older .cursorrules file in the repo root still works for now, but project rules are the recommended format.
Why put your design system in a rule?
A prompt like "build a settings page" says nothing about color, type or spacing, so the model picks defaults. A design rule makes those decisions once. Every later prompt can stay short, and the result still matches your product.
Set up a design rule in four steps
Pick a system from the design system examples, or write your own DESIGN.md.
Create the file
.cursor/rules/design.mdc.Add the frontmatter shown below.
Paste the DESIGN.md under the frontmatter.
---
description: Design system for all UI work
alwaysApply: true
---
# Design system
(paste your DESIGN.md here)Always on, or attached by file type?
A Cursor rule can be always on, attached automatically when files match a glob, chosen by the Agent from its description, or called by hand with an @-mention. For a design system, always on is the simplest choice. If your repository mixes backend and frontend code, set alwaysApply: false and add globs: **/*.tsx, **/*.css so the rule only loads for UI files.
Keep the rule short
Cursor's own guidance is to keep a rule focused and well under 500 lines. A full DESIGN.md can be long, so keep the tokens, the type scale and the component rules, and cut long background prose. Shorter rules are followed more reliably.
What about AGENTS.md and CLAUDE.md?
Other tools read other files. Claude Code reads CLAUDE.md, so add one line there: "Follow DESIGN.md for all UI." Cursor also reads AGENTS.md. Keep DESIGN.md as the single source and point each tool to it, instead of maintaining three copies.
Check that it works
Open a new chat and ask for a pricing card without naming any colors or fonts. Compare the result with your file. If the output ignores it, check that the file ends in .mdc, that the frontmatter sits on the first line and that alwaysApply is set.
You can also combine it with a layout rule. A PATTERN.md describes the page structure, and DESIGN.md describes the look.
Frequently asked questions
What are Cursor rules?
Cursor rules are persistent instructions that Cursor adds to the Agent's context. Project rules are Markdown files with frontmatter in the .cursor/rules folder, so they live in your repository and apply to everyone who works on it.
Where do Cursor rules go?
In the .cursor/rules folder at the root of your project, as .mdc files, for example .cursor/rules/design.mdc. The older .cursorrules file in the repo root still works for now, but project rules are the recommended format.
Can I use a DESIGN.md as a Cursor rule?
Yes. Save the DESIGN.md content in .cursor/rules/design.mdc and set alwaysApply: true in the frontmatter. Cursor then applies your colors, type scale and spacing to every Agent run, so you do not repeat them in each prompt.
How long should a Cursor rule be?
Keep it focused. Cursor's guidance is to stay well under 500 lines per rule. For a design system, keep tokens, type scale and component rules, and cut long explanatory prose.