Skip to content
.mdDesign.md Store
Back to Blog
cursorcursorrulesdesign.md

Your Brand Constitution: How to Wire DESIGN.md Into Your .cursorrules

Most .cursorrules files cover code style. Few cover design. Here's how to connect your DESIGN.md spec to Cursor so every AI-generated component respects your visual system — automatically.

If you use Cursor, you probably have a .cursorrules file. It tells the AI what framework you're using, how to name variables, which patterns to follow. It's one of the most effective levers for getting consistent output from an AI coding assistant.

What most .cursorrules files don't cover is design.

They'll specify TypeScript strict mode, Next.js App Router conventions, Tailwind class ordering — everything about code quality. But when it comes to what a button should look like, what border radius a card should have, or which hex value represents "primary action" in this codebase, the file is silent. The AI guesses.

This is the gap that a DESIGN.md file closes — and connecting the two is straightforward.

What .cursorrules actually does

.cursorrules is a persistent context file that Cursor reads at the start of every session. Everything in it becomes part of the AI's working context without you having to re-explain it in each conversation. It's the closest thing Cursor has to a project-level memory.

Most teams use it for:

  • Language and framework preferences
  • Naming conventions and file structure rules
  • Anti-patterns to avoid
  • Testing requirements

What it's missing is a visual specification layer — the rules that govern how generated components should look, not just how they should be structured.

The two approaches: inline vs. reference

There are two ways to bring your design system into .cursorrules.

Option 1 — Inline the critical values

For smaller design systems, paste the most-used values directly into .cursorrules:

## Design System

Colors:
- Primary: #635bff (Stripe violet — use for CTAs, links, active states)
- Background: #0a2540 (dark navy — page and card backgrounds)
- Surface: #1a3a5c (elevated surfaces, modals)
- Text primary: #ffffff
- Text secondary: rgba(255,255,255,0.7)

Typography:
- Font: "Sohne", system-ui, sans-serif
- Heading weight: 700, tracking: -0.02em
- Body: 16px / 1.6, weight 400

Components:
- Buttons: border-radius 6px, padding 12px 24px, font-weight 600
- Cards: border-radius 12px, border: 1px solid rgba(255,255,255,0.1)
- Inputs: border-radius 6px, border: 1px solid #3d5a80, padding 10px 14px

This works. The AI will apply these values consistently across the session. The downside is maintenance — when your design system evolves, you're updating two places.

Option 2 — Reference your DESIGN.md directly

The cleaner approach is to keep DESIGN.md as the single source of truth and reference it from .cursorrules:

## Design System Reference

The project's visual specification is in DESIGN.md at the project root.
Before generating any UI component, read the relevant sections:
- Section 2 (Color Palette) for all color decisions
- Section 3 (Typography Rules) for text styling
- Section 4 (Component Stylings) for component-specific specs
- Section 5 (Layout Principles) for spacing values

Use the Agent Prompt Guide in Section 9 as the starting point for
common component generation requests.

Never invent design values. If a value is not in DESIGN.md, ask.

With this setup, Cursor reads .cursorrules, which tells it to read DESIGN.md, which contains the full visual specification. One source of truth. Both files stay in sync because DESIGN.md is the one you update.

A practical .cursorrules template

Here's a complete template that wires both concerns together — code conventions and design system:

# Project Rules

## Stack
- Next.js 16 App Router
- TypeScript strict
- Tailwind v4
- pnpm

## Code conventions
- Server components by default. Add "use client" only when needed.
- No silent `any`. Zod at every input boundary.
- Use `next/link` for internal navigation, never `<a>`.
- File naming: kebab-case for pages and components.

## Design system
The visual specification lives in DESIGN.md at the project root.

When generating UI components:
1. Read Section 2 (Color Palette) for all color values — use hex codes exactly
2. Read Section 3 (Typography Rules) for font sizes, weights, and tracking
3. Read Section 4 (Component Stylings) for border-radius, padding, and states
4. Read Section 5 (Layout Principles) for spacing scale

For common components (buttons, cards, inputs, navigation), use the
Agent Prompt Guide in Section 9 as your starting point.

Never invent values not present in DESIGN.md. Never use generic Tailwind
defaults for brand-critical properties (color, radius, typography).

## What not to do
- No hardcoded colors outside DESIGN.md values
- No inline styles for design-system properties
- No generic "bg-blue-500" — use the semantic values from DESIGN.md

The key line is the last rule block. "No generic bg-blue-500" is the practical constraint that prevents the AI from defaulting to Tailwind's color palette instead of your brand palette.

Why this matters at scale

For a solo developer building quickly, .cursorrules + DESIGN.md is a consistency tool. For a team, it's a governance mechanism.

Consider what happens when three developers are all using Cursor on the same product. Without a shared design specification in .cursorrules, each developer's AI sessions produce subtly different visual output. The primary button gets three different border-radii across three different features. The card shadow is shadow-md in one place and shadow-lg in another. Nobody notices until there's a design review, and then the rework is expensive.

With DESIGN.md referenced in .cursorrules, every developer's AI sessions start from the same visual specification. The AI makes the same color decision in feature A that it makes in feature B, because both developers' Cursor instances are reading the same source of truth.

This is what "brand constitution" means in practice: a document that governs every AI generation in the project, the same way a legal constitution governs every law — not by being present in every conversation, but by being the reference point that all decisions trace back to.

Getting your DESIGN.md

If you don't have a DESIGN.md yet, writing one from scratch takes time — extracting production values, naming semantic roles, writing component specs at the precision level that actually guides AI output consistently.

The faster path is to start with a pre-built file from Design.md Store and adapt it to your brand. The library covers design systems across retail, finance, tech, food and beverage, and more — each file structured to the open DESIGN.md specification and immediately usable in a .cursorrules reference.

Download one, adapt the hex values and typography to match your brand, drop it in your project root, and wire it into .cursorrules using the template above.

Your next Cursor session will generate on-brand components from the first prompt.