Rule Files for Standards | Claude Code Guide

CLAUDE.md gives Claude the overview. "This is a website, use dark colors, here's how the folders are organized." But what happens when you need detailed instructions for specific topics? You could stuff everything into CLAUDE.md. But at 200 lines, it becomes a wall of text. Claude reads all of it every time, even when it's doing a task that only relates to one section. Rule files solve this. They're focused documents that live in `.claude/rules/`. Claude reads them automatically based on what it's working on. ## Rules vs. CLAUDE.md Think of it this way: - **CLAUDE.md** = "What is this project?" The overview. The elevator pitch. 10-30 lines. - **Rule files** = "How do we do X correctly?" The detailed manual. One topic per file. You wouldn't put your entire company handbook in a one-page summary. Same principle. CLAUDE.md is the summary. Rules are the handbook chapters. ## Where Rules Live ```text my-website/ .claude/ rules/ design.md content.md structure.md CLAUDE.md index.html ... ``` Each `.md` file in `.claude/rules/` is one rule file. Claude reads them automatically. You don't need to reference them in CLAUDE.md or tell Claude to look at them. They just work. ## Your First Rule File Let's say you have specific design standards for your website. Create `.claude/rules/design.md`: ```markdown # Design Standards ## Colors - Background: #1a1a1a (almost black) - Text: #f0f0f0 (off-white) - Accent: #00ff88 (bright green) - Muted text: #888888 (gray) ## Typography - Headings: bold, uppercase - Body text: regular weight, 1.6 line height - Font: Inter for everything ## Layout - Maximum content width: 800px - Sections separated by a thin gray line - No rounded corners anywhere - Consistent spacing: 20px between elements, 60px between sections ## Don'ts - No gradients - No shadows - No animations that take more than 0.3 seconds - No light backgrounds ``` Now every time Claude works on anything design-related, it follows these standards. You don't remind it. You don't repeat yourself. The rules are there, Claude reads them. ## Keep Rules Short Here's something I learned the hard way: long rule files get ignored. Just like a bloated CLAUDE.md, too many instructions means Claude starts missing things. I try to keep each rule file under 100 lines. Many of mine are just 20-30 lines. Short, focused, scannable. What makes a rule file short: - **Bullet points, not paragraphs.** "Use 2-space indentation" beats a paragraph explaining why. - **No code examples.** Just describe what you want. Claude knows how to write code. - **One topic per file.** If you're covering two unrelated things, make two files. If a rule file is getting long, ask Claude to help trim it: "Read my design.md rule file and make it more concise. Keep the essential rules, remove redundancy, no code examples." ## Path-Specific Rules Here's a powerful feature: rules that only apply to certain files or folders. Say you have API-specific standards that only matter when working in your `api/` folder. You can scope rules using a `paths` field at the top of the file: ```markdown --- paths: - "api/**/*.js" --- # API Rules - All endpoints return JSON - Include error handling for every route - Log all incoming requests ``` This rule only loads when Claude is working with JavaScript files in the `api/` folder. When Claude is editing your CSS or HTML, these rules stay out of the way. The `paths` field supports patterns: - `**/*.css` - All CSS files anywhere - `src/**/*` - Everything in the src folder - `*.html` - HTML files in the root only - `components/**/*.js` - JavaScript files in components Use path-specific rules when: - Different folders have different conventions - You want to keep unrelated rules from cluttering context - You have language-specific or area-specific standards Most projects don't need this. But it's useful to know it exists. ## When to Use Rules (Not CLAUDE.md) Create a rule file when: - **The topic needs more than 5 lines.** If your design standards are 30 lines, they belong in a rule file, not crammed into CLAUDE.md. - **The instructions are topic-specific.** CSS rules don't need to load when Claude is writing content. Separate topics, separate files. - **You keep correcting the same mistake.** If Claude keeps using the wrong font or putting files in the wrong folder, write a rule that prevents it. Stick with CLAUDE.md when: - It's a general project fact (name, purpose, tech stack) - It's short (one or two lines) - It applies to everything, not just one topic ## Example Rule Files **content.md** - Writing standards ```markdown # Content Rules ## Tone - Professional but conversational - No jargon unless explained - Short paragraphs (3-4 sentences max) ## Formatting - Every page needs an H1 heading - Use H2 for sections, H3 for subsections - Lists are preferred over long paragraphs ## SEO - Every page needs a title tag (under 60 characters) - Every page needs a meta description (under 160 characters) - Use descriptive link text, never "click here" ``` **structure.md** - Project organization ```markdown # Project Structure ## Folders - pages/ - All HTML pages - css/ - Stylesheets - images/ - All images (photos, icons, logos) - docs/ - Planning documents (not part of the website) ## File Naming - Lowercase only - Dashes instead of spaces: about-me.html not about me.html - Descriptive names: team-photo.jpg not IMG_4523.jpg ## Rules - New pages go in pages/ - New images go in images/ - Never create files in the project root (except index.html) ``` ## How I Use Rules I have 13 rule files for my website. One for CSS conventions (every available class name, so Claude uses existing styles instead of inventing new ones). One for database patterns. One for security practices. One for how controllers should be structured. Sounds like a lot. But each one grew from a real problem. The CSS rules file exists because Claude kept creating duplicate styles. The security file exists because I wanted consistent escaping patterns. Every rule traces back to something Claude got wrong that I never wanted to correct again. You probably won't need 13 rule files for a personal website. One or two is plenty to start. Design standards and content rules cover most cases. ## A Simple Workflow Here's how rules develop naturally: 1. You start a project with just CLAUDE.md 2. Claude does something wrong (uses the wrong color, puts a file in the wrong place) 3. You correct Claude in the conversation 4. It happens again in a later session (Claude forgot, new session) 5. You create a rule file so it never happens again That's the whole process. Rules are crystallized corrections. They turn one-time fixes into permanent standards. For the complete reference on rule files, see the [official documentation](https://code.claude.com/docs/en/memory#modular-rules-with-claude-rules). > Next up: keeping your project organized as it grows. Because a messy project confuses Claude as much as it confuses you.

Teaching Claude Code Your Standards with Rule Files

Rules vs. CLAUDE.md

Sign In to Unlock

Check Your Email