Brand guidelines your AI coding tools can follow
How to give Cursor, Claude Code, Lovable or v0 brand rules they can follow: design tokens for values, a DESIGN.md for intent, and what each one does.
- Guide
- October 2026
- 5 min read
AI coding tools follow what’s written down and in the repo. Give them two things: design tokens (the exact values for color, type and spacing) and a DESIGN.md file (the intent: when to use what, and what never to do). Tokens keep values consistent, and the DESIGN.md keeps decisions consistent.
More and more product and marketing UI is written with AI coding tools: Cursor, Claude Code, Lovable, v0. They are fast, and they are good at producing something that works. What they don’t have is your brand. Unless it’s written down where they can read it, every prompt starts from the tool’s defaults, and the product drifts a little further from what you designed.
Why does the brand drift with every prompt?
Without rules, a model falls back on its defaults, so the product slowly starts to look like every other app built with the same tool. It picks a blue that looks fine, a radius that looks fine, a spacing that looks fine. Each choice is reasonable on its own. Together, over a few hundred prompts, they turn your product into a generic one.
Brand guidelines in a PDF don’t help here. The tool can’t open them, and even if it could, a PDF describes how the brand looks, not which component to use when. The rules have to live in the repo, in two forms: values and intent.
Design tokens: the values
Design tokens are the brand’s exact values, stored as variables in code: color, type scale, spacing, radius and shadow. They can be CSS variables, a Tailwind config or a JSON file that generates both. The format matters less than the rule that every value in the product comes from them.
Tokens work with AI tools for a simple reason: tools can’t invent a new blue if only one blue exists. When the palette is five named colors instead of an open color picker, the model reuses them. When spacing is a scale of six steps, it stops guessing at 13 pixels.
- Name tokens by role, not by value: “accent” and “surface” instead of “blue-500”. Roles tell the tool where a value belongs.
- Keep the set small. Fewer tokens leave fewer wrong choices.
- Remove hard-coded values from the codebase over time, so the tool doesn’t learn from them.
DESIGN.md: the intent
A DESIGN.md is a short markdown file in the repo root that explains what tokens can’t: how the brand should feel and how its parts are meant to be used. It usually covers:
- The brand’s character in a few lines. “Calm, precise, no exclamation marks” gives a tool more to work with than a mood board.
- Which components to use for what. Primary buttons for one action per screen, cards only for items a user can open, tables for anything people compare.
- Do’s and don’ts. No gradients on buttons. No icons without labels in navigation. Never more than two type sizes in a card.
- Accessibility rules: contrast, focus states, minimum tap sizes, text alternatives.
- Examples: a few short snippets or links to screens that get it right.
Google Labs has published an open DESIGN.md format for this, with a written spec. As of October 2026 it is still in alpha and under active development, so treat it as an emerging format rather than a standard. The idea works either way: any tool that reads files from your repo can read a DESIGN.md.
DESIGN.md vs tokens: which wins?
Both. Tokens without intent lead to correct colors used in the wrong places: the accent color on every button, the error red used for emphasis. Intent without tokens leads to the right idea with drifting values: the tool understands “calm and precise” but picks a new gray every time.
Tokens keep values consistent. The DESIGN.md keeps decisions consistent.
What should a brand hand to an AI agent?
Four things, in this order:
- Tokens in code. Every value the brand uses, named by role, in the repo.
- A DESIGN.md. The intent, the rules and the things never to do, in plain language.
- Reference screens. A few finished pages or flows the tool can look at and match.
- A component library the agent is told to reuse. If a button exists, the tool should import it, not draw a new one.
Then tell the tool to use them. Most AI coding tools read a rules or instructions file at the start of a session. Point it at the DESIGN.md and the tokens, and ask it to reuse existing components before creating new ones.
formform.co itself is custom code built with Claude, and runs on exactly this setup.
Where this fits in a brand identity
A brand identity used to end with a PDF of guidelines. For a SaaS or AI product, it should also end with tokens and a DESIGN.md, because some of the people building with your brand are now tools. The rules are the same ones a good identity system always had; they just need to be written for a new kind of reader. More on that in Systems outlive logos and Where AI belongs in a design workflow.
Our brand identity work starts at US$6k and includes design tokens where they help. Details on our services page.
If you want brand rules your team and your tools can both follow, send your brief.
Asked & Answered
A markdown file that tells AI coding tools how your product should look and behave. It usually lives in the repo root and covers the brand’s character, which components to use for what, do’s and don’ts, and accessibility rules.
Put tokens in code, add a DESIGN.md, and tell the tool to read it before generating UI. Then give it reference screens and a component library it is told to reuse, so it extends what exists instead of inventing new patterns.
Both. Tokens without intent lead to correct colors used in the wrong places. Intent without tokens leads to the right idea with drifting values. Tokens hold the values, the DESIGN.md holds the decisions.
Not yet. Google Labs has published an open DESIGN.md format, which as of October 2026 is still in alpha. The idea works with any tool that reads files from your repo, whatever format you follow.
Keep reading
- Systems outlive logosA logo is a snapshot. A system is a grammar. Design the rules, not the artifact.
- Design for technical founders: work your engineers can buildHow technical founders can judge design work, and how design should reach engineering without a translation step: tokens, components and code.