How to make Cursor use your brand colors

Cursor is fast. You describe a component, it generates the code. But the colors are always wrong. Every button is indigo. Every background is white. Every card has a slate border.

You fix one component. Open another file. Same problem. Cursor doesn't remember your corrections. It doesn't know your palette exists. Every new generation starts from zero.

There's a fix. Two files, five minutes, and Cursor uses your brand colors on every component it generates.

How Cursor picks up context

Cursor indexes your workspace. Every file in your project becomes potential context for code generation. When you ask Composer to build a component, it looks at your existing code, your configuration files, and any documentation in the project to understand how things work.

This means Cursor already knows how to find your color palette. It just needs a file to find.

Cursor also has a dedicated rules system. Files in .cursor/rules/ are treated as persistent instructions — context that's always active, not just available. This is the key to making palette enforcement consistent.

Step 1: Add COLORS.md to your project root

Generate a palette on Paletter and export the COLORS.md file. Drop it in your project root, alongside your package.json.

This file contains your full palette with roles (background, ink, accent, support, neutral), hex values, RGB equivalents, pre-computed WCAG contrast ratios, CSS custom properties, Tailwind v4 tokens, and usage rules.

Cursor's workspace indexer picks up COLORS.md automatically. When Composer generates a component, it can reference the palette data. This alone makes a significant difference — Cursor stops defaulting to Tailwind's built-in colors and starts using yours.

Step 2: Add it to .cursor/rules

For stronger enforcement, copy your COLORS.md into .cursor/rules/colors.md. Files in the rules directory are treated as persistent instructions that Cursor follows on every generation.

The difference matters. A file in the project root is available context — Cursor might use it, might not. A file in .cursor/rules/ is active context — Cursor always follows it.

You can also add a separate rule file that references the palette. Create .cursor/rules/design-system.md with instructions like:

• Always use the color palette defined in COLORS.md
• Use semantic CSS variables (var(--color-bg), var(--color-text)) instead of raw hex values
• Never invent colors outside the defined palette
• Check contrast ratios before placing text on colored backgrounds
• Follow all rules listed in the palette's Rules section

Now Cursor treats your palette as a hard constraint. Not a suggestion.

The difference in practice

Without COLORS.md — Composer prompt: "Build a pricing card with a highlight tier"

Cursor generates a card with bg-white, text-gray-900, border-gray-200, and a highlighted tier with bg-indigo-600 and text-white. Looks like every SaaS pricing page. No relation to your brand.

With COLORS.md — same prompt:

Cursor generates a card using var(--color-bg) for the surface, var(--color-text) for headings, var(--color-muted) for the border, and the highlighted tier uses var(--color-primary) with var(--color-text) for text (because it checked the contrast ratio and knows that combination passes AA). Secondary text uses var(--color-secondary).

Your brand. Your colors. Your rules. No corrections needed.

Inline edits and tab completions

COLORS.md doesn't just work with Composer. Cursor's inline edit feature (Cmd+K) also picks up workspace context. When you highlight a section of code and ask Cursor to restyle it, it references your palette.

Tab completions are more limited — they're based on immediate context rather than full workspace indexing. But if you're working in a file that already imports your CSS variables or uses your Tailwind tokens, tab completions will suggest the correct values.

The pattern reinforces itself. The more components use your palette tokens, the more Cursor's completions suggest those tokens. Consistency compounds.

Tips for Cursor-specific workflows

Use Composer for new components. Composer has the best access to workspace context. When generating a new component from scratch, Composer reads COLORS.md and applies your palette. Inline edits work well for modifications, but Composer is where the palette context shines.

Keep COLORS.md in both locations. Project root for general availability. .cursor/rules/ for enforcement. Belt and suspenders. The duplication is worth the consistency.

Reference colors by variable name in prompts. Instead of "make the button orange," say "use the accent color for the button." Cursor maps "accent color" to your palette's accent role and applies the right token. Semantic language produces semantic code.

Regenerate when your palette changes. If you update a color on Paletter, re-export and replace both copies of COLORS.md. Old tokens mean old colors. One click to regenerate, two files to replace.

For the full setup guide, see the Cursor integration page.