Path-scoped rules

After the always-on project memory above, there is a lighter-touch way to give Claude rules: ones that switch on only when they are relevant. A path-scoped rule is an instruction that loads only when you are editing the files it is about, so the guidance shows up at the right moment and stays out of the way the rest of the time.

What aims a rule at the right files is a glob, a wildcard matching pattern for file paths, like every test file wherever it lives, or anything inside the terraform folder. The rule is the instruction, and the glob is how and where it is applied. So the same rule can be scoped to one folder or to one kind of file, whichever fits.

This earns its keep when a convention applies to files spread across the project. Test files, for instance, sit next to every component all over the tree. A CLAUDE.md only covers the folder it sits in, so to reach them all you would drop a copy into every folder and keep them in sync. One glob rule covers them in a single place, following the file type wherever it lives.

Say it another way

A path-scoped rule is like a sticky note that only appears on the drawer you have actually opened. You get the right reminder exactly when you are working on that part, not all of them at once.

The pattern written on the note, the glob, is what says which drawer. And because it can follow the kind of file rather than the folder, one note covers the same thing wherever it is kept, instead of taping a copy inside every cupboard.

A path-scoped rule loads only when the file you are editing matches its glob, so the right guidance appears just in time and nothing irrelevant is carried the rest of the time.

What one actually looks like

There is no magic to the file. A rule is a folder, a file, and one line of frontmatter saying which files it is about. This is the case the page describes above: a convention for test files, which sit next to every component all over the tree.

.claude/rules/tests.md
---
paths: ["**/*.test.ts", "**/*.test.tsx"]
---

Conventions for test files, wherever they live in the tree.

- Test what the caller expects to happen, not how the code currently
  does it.
- Cover the edge cases as well as the happy path: the null, the empty
  and the boundary.
- Keep each test to one behaviour, so a failure names the problem
  without anyone having to read the test.

The glob is the only thing that makes this different from an always-on rule. It points outward at the work, so the file sits in the rules folder either way and only loads when a matching file is open.

Doing this with Claude Code: Path-scoped rules

Put a rule in a .claude/rules/ file with a paths glob, so it loads only for the files it is about.

Aim it with a glob. A wildcard pattern for file paths decides when the rule switches on, scoped either to a folder or to a kind of file.

It keeps context lean. The rule stays out of the way until you touch a matching file, so Claude is not carrying guidance it does not need.

Better than a scattered CLAUDE.md. When the same kind of file lives all over the tree, one glob rule beats dropping a CLAUDE.md copy into every folder and keeping them in sync.

Common questions

What exactly does the glob point at?
The work, not the rule. The rule always lives in the rules folder regardless, and the glob written on it is the condition saying which files it is about. It points outward.
When does the rule get handed over?
When Claude opens a file whose path matches. No match and the rule stays in the drawer, so the guidance appears just in time rather than being carried all the time.
Does splitting a big file into topics save context?
No, on its own it only makes the scope and detail easy to review. Plain rules and imports all load at launch anyway. The saving comes from adding the path scope, so only the relevant topic loads.
What does that look like in practice?
While you are working out how to format a commit message you do not need the rules for how account logins work. The move is two parts: split by topic so it is reviewable, then path-scope so only what is needed loads.
Should I anchor a rule to a folder or to a file type?
Whichever fits the convention. Anchoring to a folder pins it to that location however deeply nested, where anchoring to a file type sweeps every location and catches that kind of file wherever it lives.
When is a folder-level file good enough?
When the files you care about are grouped in one folder. It only covers the folder it sits in, which is fine if that is where they all are.
And when does the glob rule win?
When the same kind of file is spread across the tree, like test files sitting next to every component. The alternative is dropping a copy into every folder and keeping them all in sync, where one glob rule covers them in a single place.

Back to For developers. The craft around it is Working with AI.