Setting Up Brand Rules in Claude, Cursor, and Copilot: A Complete Guide
Three tools, three file formats, one brand
Setting Up Brand Rules in Claude, Cursor, and Copilot: A Complete Guide
Three tools, one problem
Your team uses Claude for writing. Cursor for coding. GitHub Copilot for auto-completion. Each tool has a different mechanism for loading custom instructions. None of them talk to each other. And none of them know your brand exists unless you explicitly tell them.
The result: Claude writes marketing copy in a generic helpful tone. Cursor generates components with default colors. Copilot suggests variable names that do not follow your naming conventions. Every output requires manual review and correction. The AI is fast but wrong, which is slower than doing it right the first time.
The fix is not complicated. Each tool has a designated place for custom rules. You write the rules once, format them for each tool, and commit them to your repo. From that point forward, every AI interaction starts with your brand context loaded.
This guide covers the exact setup for each tool, with examples you can copy and adapt.
Claude: CLAUDE.md
Claude reads a file called CLAUDE.md at the root of your project. This file is loaded automatically when Claude Code starts a session, and it applies to every interaction within that project.
Where it goes: Root of your repository, named exactly CLAUDE.md.
What it contains: Everything Claude needs to know about your brand: voice rules, visual constraints, terminology, do/don't lists, and context-specific behavior.
Step 1: Create the file.
touch CLAUDE.md
Step 2: Add your brand identity.
# Brand: Acme Corp
## Voice
Clear, confident, evidence-led. Short paragraphs. No jargon unless the audience is technical.
- Default tone: professional but warm
- Support context: empathetic, action-oriented. Apologize once, then fix forward.
- Marketing context: bold claims backed by data. Never use "innovative" or "revolutionary."
- Technical docs: precise, complete, no humor
## Terminology
- Say "workspace" not "dashboard"
- Say "team member" not "user"
- Say "connect" not "integrate"
- Never say "synergy," "leverage," or "utilize"
## Visual rules
- Primary color (#2563EB): CTAs and hero elements only
- Secondary color (#64748B): body text and secondary elements
- Font: Inter for all UI text, JetBrains Mono for code
- Never hardcode colors. Always use CSS custom properties or Tailwind classes
## Constraints
- No superlatives unless backed by data
- No competitor mentions by name
- All claims must be verifiable
- Error messages: one sentence explaining what happened, one sentence explaining what to do
Step 3: Commit and push.
git add CLAUDE.md
git commit -m "docs: add brand rules for Claude"
git push
Claude Code now loads these rules automatically for every session in this project. When you ask Claude to write an error message, it uses empathetic tone. When you ask for marketing copy, it backs claims with data. No prompting required.
Advanced: nested CLAUDE.md files. Claude supports CLAUDE.md files in subdirectories. A CLAUDE.md in /packages/marketing/ overrides the root file for that directory. Use this for monorepos where different packages have different voice requirements.
Cursor: .cursorrules
Cursor reads a file called .cursorrules at the root of your project. This file is loaded when the editor opens and applies to all AI-assisted code generation within the project.
Where it goes: Root of your repository, named exactly .cursorrules.
What it contains: Code-specific rules: naming conventions, component patterns, styling constraints, and architectural decisions.
Step 1: Create the file.
touch .cursorrules
Step 2: Add your coding standards.
# Acme Corp - Code Standards
## Component conventions
- React components use PascalCase: Button, HeroSection, PricingCard
- Hooks use camelCase with "use" prefix: useAuth, useBrandContext
- Props are typed with TypeScript interfaces, never PropTypes
- Every component has a JSDoc comment explaining its purpose
## Styling
- Use Tailwind CSS utility classes, never inline styles
- Color values come from the design system: primary, secondary, accent
- Never hardcode hex values. Use CSS custom properties or Tailwind theme
- Responsive: mobile-first, breakpoints at sm (640), md (768), lg (1024)
## Brand-specific patterns
- CTA buttons always use the primary color class: bg-primary text-white
- Error states use the destructive variant, never red-500
- Loading states use skeleton components, never spinners
- Empty states always include a helpful message and a primary action
## File organization
- Components in src/components/{feature}/
- Hooks in src/hooks/
- Types in src/types/
- Constants in src/lib/constants.ts
## Do not
- Do not use default exports (use named exports)
- Do not use any type (use unknown or specific types)
- Do not use console.log in production code (use the logger utility)
- Do not generate placeholder content. Use real brand copy from the design system
Step 3: Commit and push.
git add .cursorrules
git commit -m "docs: add brand coding standards for Cursor"
git push
When Cursor generates a component, it now follows your naming conventions, uses your design system colors, and structures files the way your team expects. The difference is immediate: fewer corrections, faster reviews, consistent output.
For a deeper comparison of these two formats, see our guide on CLAUDE.md vs .cursorrules.
GitHub Copilot: instruction files
GitHub Copilot supports custom instructions through repository-level instruction files. The mechanism has evolved, but the current approach uses a .github/copilot-instructions.md file.
Where it goes: .github/copilot-instructions.md in your repository.
What it contains: Natural language instructions that Copilot uses as context for code suggestions and chat responses.
Step 1: Create the directory and file.
mkdir -p .github
touch .github/copilot-instructions.md
Step 2: Add your instructions.
# Acme Corp - Copilot Instructions
## Code style
- TypeScript strict mode. No implicit any.
- Prefer named exports over default exports
- Use descriptive variable names. No single-letter variables except in loops
- Every function has a JSDoc comment
## Brand constraints
- UI text must follow brand voice: clear, confident, evidence-led
- Button labels: use action verbs ("Get started", "View report", not "Click here", "Submit")
- Error messages: explain what happened and what to do next
- Never generate placeholder text like "Lorem ipsum." Use real copy
## Architecture
- API calls go through src/lib/api.ts, never called directly from components
- State management through React Query for server state, Zustand for client state
- Authentication checks use the useAuth hook, never manual token checks
- All routes are protected by default. Public routes are explicitly marked
## Testing
- Every component has at least one test
- Tests use React Testing Library, not Enzyme
- Test user behavior, not implementation details
- Mock API calls with MSW, not manual mocks
Step 3: Commit and push.
git add .github/copilot-instructions.md
git commit -m "docs: add brand instructions for GitHub Copilot"
git push
Copilot now uses these instructions as additional context when generating suggestions. The specificity matters: the more concrete your rules, the better Copilot follows them.
Keeping all three in sync
The challenge with three files is drift. You update the voice rules in CLAUDE.md but forget to update .cursorrules. The primary color changes and Copilot still suggests the old one.
Option 1: Manual sync. Maintain a checklist. When brand rules change, update all three files in the same commit. This works for small teams. It breaks at scale.
Option 2: Single source, generated outputs. Maintain one canonical brand file and generate the tool-specific files from it. A simple build script can transform a brand.yaml into CLAUDE.md, .cursorrules, and copilot-instructions.md.
# brand.yaml - single source of truth
voice:
default: "Clear, confident, evidence-led"
support: "Empathetic, action-oriented"
marketing: "Bold claims backed by data"
colors:
primary: "#2563EB"
secondary: "#64748B"
terminology:
preferred:
- { use: "workspace", not: "dashboard" }
- { use: "team member", not: "user" }
A script reads this file and generates three outputs. One change, three files updated. No drift.
Option 3: BrandMythos. Upload your brand guide once. We generate every format: CLAUDE.md, .cursorrules, AGENTS.md, design tokens, system prompts, and knowledge graphs. When your brand evolves, regenerate. Every tool gets the same update simultaneously.
What changes immediately
Teams that set up brand rules across all three tools report consistent results:
- 65% fewer review corrections on AI-generated content
- 40% faster onboarding for new developers who can read the rules instead of absorbing tribal knowledge
- Consistent voice across marketing copy, product UI, and support responses
- No more "that does not sound like us" feedback in pull request reviews
The setup takes 30 minutes per tool for a basic configuration. An hour if you want the advanced features. After that, every AI interaction in your project starts with brand context. The compound effect over weeks and months is significant.
Common setup mistakes
Too vague. "Write in a professional tone" gives the AI nothing to work with. "Clear sentences under 20 words, no jargon, data over adjectives" gives it a framework.
Too long. A 5,000-word CLAUDE.md is worse than a 500-word one. Agents have context limits. Keep rules concise and prioritized. The most important rules go first.
No examples. Rules without examples are open to interpretation. "Use empathetic tone" means different things to different agents. "Use empathetic tone. Example: 'We understand this is frustrating. Here is how to fix it.'" is unambiguous.
Forgetting to commit. Brand files in your local editor help you. Brand files committed to the repo help everyone. Commit them. Review them in PRs. Treat them as code.
Not testing. After setup, test each tool. Ask Claude to write an error message. Ask Cursor to generate a component. Ask Copilot to write a function. If the output does not match your brand, the rules need refinement.
Next steps
Start with the tool your team uses most. Write the brand rules. Commit the file. Test the output. Then expand to the other tools.
Or skip the manual work entirely. Sign up for BrandMythos and get all three files generated from your existing brand guide in minutes. One upload, every format, every tool.
Stay in the loop
Get brand intelligence insights delivered
Occasional deep dives on brand systems, AI governance, and what happens when guidelines become loadable infrastructure.
No spam. Unsubscribe anytime.
Share this article
Keep reading
The ROI of Brand Governance: Building the Business Case for Consistency
Brand governance is not a design initiative
Brand governance is not a design initiative
brandmythos.comThe ROI of Brand Governance: Building the Business Case for Consistency
Apr 10, 2026
Brand Voice for AI Chatbots: Writing System Prompts That Sound Like You
Your chatbot speaks to customers more often than your...
Brand Voice for AI Chatbots: Writing System Prompts That Sound Like You
Apr 9, 2026
From Figma to AI: How Design Systems Become Code Generators
Your Figma design system is full of decisions: colors,...
From Figma to AI: How Design Systems Become Code Generators
Apr 8, 2026
Ready to try it?
See your brand DNA structured for agents
Enter your URL. BrandMythos extracts voice, visuals, and rules into CLAUDE.md, design tokens, and structured graphs your tools can load.