Path-specific rules for conditional loading
What this covers
- Scope a rule file to globs with YAML frontmatter
- Choose glob rules over directory CLAUDE.md when conventions cross directories
- Explain the token-cost argument for conditional loading
- Write
**/when a convention follows a file type across directories, since a single*stops at a/ - Explain that a rule with no
pathsfield loads unconditionally, which is intended rather than an error - Recognize that
pathsmatches the file being edited, so it cannot express a personal preference
process plate / 3.3
Which files does this rule follow?
Choose a paths pattern. The repository tree illuminates the files for which that rule becomes applicable.
process reading / one directory level
Only root-level Python files match.
A single star does not cross a slash, so nested Python modules stay outside this rule.
Read the complete diagram as text
- Read paths as globs evaluated against files Claude is working with.
- Use one star within a directory level and a double star across directories.
- Use a file-type glob when a convention follows a kind of file across the repository.
- Use a subtree glob when the convention belongs to one architectural region.
- Treat a rule with no paths field as unconditional configuration loaded at session start.
Key terms
- Glob pattern
- A pattern such as *.ts that selects files by name or path.
- YAML frontmatter
- A small metadata block at the top of a text file, surrounded by --- lines.
A rule file in .claude/rules/ can carry a paths field in its YAML frontmatter — the settings block at the top of the file — holding glob patterns. The rule then loads only when the file being edited matches.
paths: ["terraform/**/*"]paths is also what makes a rule conditional at all. A rule file with no paths field loads unconditionally, on every turn, like always-loaded configuration that happens to live in the rules directory. That's intended, not an error: storing a file in .claude/rules/ splits configuration into topics, and adding paths is the separate decision that narrows one.
Glob mechanics decide whether a rule ever fires
A single * matches within one directory level and doesn't cross a /. A double ** descends through directories.
pattern file being edited match?
*.py main.py yes
*.py src/pipeline/main.py no (* stops at the /)
**/*.py src/pipeline/main.py yes
packages/api/**/* packages/api/db/pool.ts yesSo paths: ["*.py"] matches Python files only at the repository root. It does not match Python files in subdirectories. A convention that applies throughout the repository needs the **/ prefix.
It matches the file, not the person
Rules posted in a study room belong to the room: whoever books it that hour follows them, whichever department they came from. There is no way to post a rule that applies only to you.
The glob is evaluated against the path of the file in hand. It knows nothing about who is editing, which team they belong to, or where the session started. The rule file's own location doesn't limit its reach either. Every rule lives in .claude/rules/, but its pattern can match files anywhere in the repository. Anyone opening a file under packages/checkout/ gets the checkout conventions, because those conventions belong to the code. That also sets a limit: paths cannot express a personal preference, which has no path to attach to.
Why conditional loading matters
Rules that are always loaded cost context on every turn, whether or not they are relevant. Conditional loading means Terraform conventions are present when you edit Terraform and absent when you don't — less irrelevant context, fewer tokens, and less noise competing for attention.
When globs are the better choice
Directory-level CLAUDE.md covers a place. Glob rules cover a kind of file.
Test files are the clearest example: **/*.test.tsx matches them wherever they live. Expressing that with directory CLAUDE.md files would mean one per directory containing tests, duplicated and drifting apart.
The rule of thumb: if a convention follows a file type rather than a location, use a path-scoped rule. If it genuinely belongs to one part of the tree, either works — with one point for the rule file, which keeps every rule in one directory somebody can review at once.
.claude/rules/YAML frontmatterpathsglob patterns
Field note — common misconceptions
- MythThat a subdirectory CLAUDE.md can cover files scattered across the tree
- ActuallyA convention following a file type needs a glob such as
**/*.test.tsx, wherever they live. - MythThat conditional loading is only a tidiness concern
- ActuallyA rule with no
pathsfield loads every turn, spending context whether relevant or not. - MythThat path scoping and directory placement are interchangeable
- ActuallyA path-scoped rule keeps every rule in one reviewable directory instead of scattering them.
Guided review
Review this lesson as a study deck
Review the lesson's main ideas in five guided slides, then test yourself with three flashcards.
Open Task 3.3 study deckCross-domain reasoning
Connect this idea
Project settings control coding work
Sessions, built-in tools, project instructions, skills, path rules, and execution mode determine what Claude knows and what it can do during a code change.
- 1.7 · Manage session state, resumption, and forking
- 2.5 · Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob)
- 3.1 · Configure CLAUDE.md files with appropriate hierarchy, scoping, and organization
- 3.2 · Create and configure custom slash commands and skills
- 3.4 · Determine when to use plan mode vs direct execution
Applied practice
Practice this lesson in a lab
Use a related lab to create a decision, implementation or diagram, evidence record, and review.
- Lab 6 · Claude Code configuration hierarchy
Place guidance, reusable procedures, scoped rules, and enforcement in the mechanism that fits each one.