Section Headers Do Not Enforce Scope — Path Rules Do

A CLAUDE.md with clear section headers — ”## Database Rules”, ”## UI Rules” — loads every section into context for every edit. Claude sees database naming conventions while generating React components and sometimes applies them. The headers are organizational aids for humans, not enforcement boundaries for the model.

Path-specific rules in .claude/rules/ are enforcement boundaries. Rules that do not match the current file’s path are structurally absent from context. They are not deprioritized, not filtered at response time, not marked as low-relevance. They do not load.

How Non-Matching Rules Behave

When editing src/components/Button.tsx:

There is no intermediate state. No “loaded but deprioritized.” No “in context but marked as inapplicable.” The Terraform and Python rules do not exist in the model’s context for this edit.

Why This Matters: The Cross-Contamination Problem

A project with 500 lines of rules across Python, R, and LaTeX reports that Claude mixes Python style rules into R code and applies LaTeX conventions in Python files.

Adding explicit instructions — “ONLY apply the following rules to Python files” — does not fix it. The instructions are text inside the same loaded context. The model processes all loaded instructions as potentially applicable guidance.

Moving each area’s rules to .claude/rules/ with path frontmatter (scripts/**/*.py, viz/**/*.R, papers/**/*.tex) fixed it completely. Cross-contamination dropped from 8 incidents per week to zero. Not because the model got smarter — because the wrong rules stopped loading.

Measured Impact

One team migrated a 500-line CLAUDE.md to 5 path-scoped rules files and tracked results over two weeks:

The 84% reduction in loaded content is not because rules were deleted — they are all still there. They just load only when relevant.

The adherence improvement (85% → 94%) is not coincidental. When Claude sees 80 lines of relevant rules instead of 500 lines of mixed content, it applies them more reliably. Less noise means better focus.

The “Claude Is Smart Enough” Argument

A team lead proposes: “Keep everything in CLAUDE.md. Claude can figure out which rules apply based on section headers.”

This conflates two separate issues:

1. Can Claude identify relevant rules? — Often yes, but not always. Similar patterns across areas (naming conventions, error handling) cause cross-application.
2. Should irrelevant rules consume context tokens? — No, regardless of how smart the model is. In a project with 7 areas and ~700 lines of rules, a focused session (1-2 areas) wastes 70-85% of its rules context on content that will never be applied.

Path rules solve both problems. They prevent cross-application by structural absence, and they free context tokens for the actual work.

The Correct Split: CLAUDE.md + Path-Scoped Rules

Universal standards that apply everywhere belong in CLAUDE.md — they always load, which is the correct behavior for universal rules.

Area-specific standards belong in .claude/rules/ with path frontmatter — they load only when editing matching files.

A Python session loads: universal standards (100 lines from CLAUDE.md) + Python rules (120 lines from python.md). Total: 220 lines instead of 450. TypeScript and infrastructure rules are absent.

Using paths: ["**/*"] for universal standards in a rules file works technically but is unnecessary complexity. CLAUDE.md already provides always-loaded behavior without needing a glob pattern.

Cross-Domain: Path Rules + MCP Tools

Path-specific rules also complement MCP tool configurations. A project with Python linter and React component MCP servers can use path-scoped rules to guide tool selection — Python rules activating for src/api/ files, React rules for src/web/ files — ensuring the model uses the right MCP tools for the right code area.

One-liner: Non-matching path rules are absent from context, not deprioritized — this structural absence eliminates cross-contamination and frees 70-85% of wasted rules tokens.