Apply path-specific rules for conditional convention loading

Path-specific rules live in the .claude/rules/ directory of your project. Each rule is a plain markdown file, and what makes it conditional is an optional block of YAML frontmatter at the top. The paths field takes a list of glob patterns; the markdown body below the frontmatter is the actual guidance Claude should follow.

.claude/
  rules/
    testing.md
    terraform.md
    api-handlers.md

A single rule file looks like this:

---
paths: ["**/*.test.tsx", "**/*.test.ts"]
---
# Test conventions
- Use React Testing Library, never Enzyme.
- Query by role or label text, not by test id.
- One top-level describe() named after the unit under test.

Because .claude/ is committed to the repository, these rules are project-scoped and shared with the whole team, the same hierarchy level as the project CLAUDE.md and .claude/commands/. You can keep many small, focused rule files instead of one monolith, and each file can list several globs in its paths array.

The defining behavior of a path-scoped rule is conditional loading: its content enters the context window only when the session is working on a file that matches one of its glob patterns. Edit a Terraform file and terraform.md is pulled in; edit a React test and testing.md is pulled in; work anywhere else and neither costs you a single token.

Contrast this with the root CLAUDE.md, which is loaded on every request regardless of what you are doing. In a large codebase with conventions for tests, infrastructure, API handlers, migrations, and more, putting everything in an always-on file bloats the base context and dilutes the model's attention with rules that are irrelevant to the current file.

Path scoping fixes both problems at once. It reduces token usage, because irrelevant conventions are simply absent, and it sharpens focus, because only the conventions that apply to the file in front of Claude are present. This is the exam's stated advantage: rules load only when editing matching files, reducing irrelevant context and token usage.

The real power of glob patterns is that they match on the path and extension, not on a folder boundary. A pattern like **/*.test.tsx matches components/Button.test.tsx, features/login/LoginForm.test.tsx, and any other test file no matter how deep or where it lives. The convention is bound to the file type, not to a location.

A directory-level CLAUDE.md cannot do this. It only covers its own contiguous subtree, and it applies to every file in that subtree. It has no way to say 'just the test files' or 'just the .tf files' when those are scattered across dozens of directories, and no way to target a single extension. Common patterns you will see: **/*.test.tsx for all React test files, terraform/**/* for everything under a Terraform tree, **/migrations/*.sql for migration scripts anywhere, and **/*.stories.tsx for Storybook stories.

Colocated tests are the canonical case: teams place Button.test.tsx right next to Button.tsx, so there is no single tests/ directory to attach a CLAUDE.md to. A glob rule reaches all of them; a directory file reaches almost none.

Three mechanisms can carry conventions, and the exam expects you to pick the right one:

• Directory-level CLAUDE.md: best when a convention applies to a self-contained subtree and to essentially everything in it, for example a packages/billing/ package with its own rules.
• Path-specific rules (.claude/rules/ with paths globs): best when a convention attaches to a file type or pattern spread across many directories, for example tests, migrations, or .tf files.
• Skills (.claude/skills/): on-demand workflows that are invoked explicitly or selected by Claude for a task. They do NOT trigger automatically when you touch a matching file.

So when the requirement is 'automatically apply the correct conventions based on the file path, regardless of directory', path-specific rules are the answer. This is exactly the reasoning in the sample question about a codebase with React, API, and database conventions plus tests spread throughout: a root CLAUDE.md with headers relies on inference, per-directory CLAUDE.md files cannot reach scattered files, and skills require invocation. Only glob-scoped rule files apply the right conventions deterministically by path.

Treat rule files the way you would treat well-factored code: one topic per file. A testing.md, an api-conventions.md, and a deployment.md, each scoped to its own globs, is the modular alternative to a monolithic CLAUDE.md, the same split-by-topic idea from the CLAUDE.md hierarchy task. A single rule file may list multiple globs when one set of conventions covers several related patterns.

Keep globs as tight as the convention warrants. A broad pattern like **/* reintroduces always-on loading and mixes unrelated rules back together, undoing the benefit. Prefer extension-specific or subtree-specific patterns.

When behavior looks inconsistent, meaning a convention is or is not being applied, use the /memory command to see which memory and rule files are currently loaded. That tells you whether a path rule actually matched the file you are editing, which is the fastest way to diagnose a mis-scoped paths glob.