--- title: The Claude Code rules system description: How CLAUDE.md files give Claude persistent, project-specific instructions that carry across every session, and how to scale them as your codebase grows. author: FractionalSkill ---

The Claude Code rules system

Most operators talk to Claude Code the same way every time. They open a session, retype context, re-explain the project, and repeat themselves across every client engagement. That overhead compounds fast when you're managing three to five active clients.

CLAUDE.md files cut that out entirely.

A CLAUDE.md file is a plain markdown document that Claude Code reads automatically at the start of every session. You write the rules once. Claude follows them every time, without being reminded.

What CLAUDE.md actually is

Think of it as a standing brief for your AI. Everything you'd normally have to re-explain at the start of a session goes here instead: how the project is structured, what conventions to follow, what to avoid.

Claude Code looks for a CLAUDE.md file at the root of your project folder the moment you open a session. No commands needed. No pasting instructions. It reads the file and starts with full context already loaded.

The fastest way to generate your first one is the /init command. Type it into Claude Code and it scans your project, reads the existing files, and produces an initial rule file on its own. You don't write it from scratch. Claude Code does that work and hands you a draft.

$ claude
You: /init

Reading project structure...
Creating CLAUDE.md with initial rules...

After that, you can edit the file manually, add your own rules, remove what doesn't apply, and treat it like any other document in the project.

> The practical value for fractionals. If you're managing multiple client engagements, each client folder gets its own CLAUDE.md. One client has a strict no-Oxford-comma editorial rule. Another requires all financial figures in thousands, not millions. You write those rules once per client. They apply automatically from that point forward.

The hierarchy that scales with your codebase

Here is where the rules system becomes genuinely useful for larger projects.

CLAUDE.md files work in a hierarchy. You can place them at the root level of your project and also nest additional CLAUDE.md files inside specific subdirectories. When Claude Code works inside a particular folder, it pulls in the rules from that folder and every parent directory above it.

The rules compound as you go deeper. Root-level rules always apply. Subdirectory rules add on top of them, specific to that part of the codebase.

In practice, your root CLAUDE.md holds the high-level project context. A folder handling a client-facing dashboard might have its own CLAUDE.md with rules about visual consistency. A reporting folder might specify exactly how numbers get formatted and labeled.

As the project grows, you add rule files where you need them. Claude Code handles the rest, pulling in the right rules based on where it's currently working.

> For operators managing large client codebases. A project with dozens of folders doesn't need one enormous rule file. Distributed CLAUDE.md files keep rules specific and manageable. The rules that apply to the data pipeline don't need to appear in the UI folder.

How to create rules for specific folders

You have two options: write the file manually, or have Claude Code generate it.

Manual editing is straightforward. Create a new CLAUDE.md file inside the target folder, write the rules in plain markdown, and save. Claude Code picks it up automatically the next session.

AI-generated rules are worth deploying for any folder with meaningful complexity. Tag the folder in your Claude Code session and give it a simple instruction:

You: In this folder we need to improve our CLAUDE.md file.
     Please create an initial set of rules for this route.

Claude Code reads through the files in that directory, identifies the components being used, maps the architecture, and produces a relevant rule file. It works the same way a developer would approach a new codebase: read the code first, then document what it finds.

You can review the output, accept it, and add your own annotations on top. The workflow is collaborative, not fully automated. Claude Code generates the starting point, and you shape it into something precise.

> What Claude Code actually does during generation. It reads the component files in the folder, traces what they depend on, and documents the patterns it finds. The rule file it produces reflects the actual code, not generic advice. That makes the rules accurate from day one rather than aspirational.

Mixing manual and AI-generated rules

The most practical approach is a combination of both.

Let Claude Code generate the structural and technical rules it can infer from reading the code. Add the rules it can't infer: client preferences, editorial standards, output formats, things that exist in your head rather than in the files.

A working CLAUDE.md for a client engagement might look like this:

# Project rules

## Project context
This is a financial reporting tool for [Client Name].
All figures display in thousands (not millions).
Reports follow Q-format labeling: Q1 2025, Q2 2025, etc.

## Code conventions
- TypeScript strict mode is enforced
- Components live in /src/components, one per file
- No inline styles; use Tailwind classes only

## Output rules
- Always confirm data source before including a figure
- Section headers use sentence case, not title case

The first two rules came from the client. The last three came from the codebase. You maintain one file that holds both kinds of context, and it applies automatically without any session overhead.

> A note on rules hygiene. Review your CLAUDE.md files when an engagement changes scope. Stale rules can cause as much friction as no rules at all. Treat them as living documents, not set-and-forget configuration.

Session workflow with the rules system in place

Once your CLAUDE.md files are in place, the session experience changes noticeably.

You open a session, and Claude Code already knows the project. You don't re-explain the tech stack. You don't paste in the naming conventions. You give a task, and Claude Code executes it within the rules you've already established.

For fractional leaders moving between client engagements, this matters. Each client folder has its own rule system. Navigate to the folder, open a session, and the right context loads automatically. The rules that apply to one client don't bleed into another.

The hierarchy means you can also delegate rule creation as the project grows. Ask Claude Code to read a new feature folder and produce a CLAUDE.md for it. Review and refine. That's repeatable at any scale.

The real value is cumulative. Rules you write today reduce the overhead of every session that follows. The more precisely the rules describe the project, the less correction happens mid-task, and the less time you spend redirecting Claude Code toward what you already know.