CCAF logo

Domain 3 · Task 3.3

Path-Specific Rules

Apply path-specific rules for conditional convention loading.

Path-specific rules let a convention load only when Claude edits a file that matches a glob, instead of being always-on context. They live in .claude/rules/ with YAML paths frontmatter. The decisive distinction is *what the convention follows*: a file type spread across the codebase needs a glob rule; a convention bound to one directory can stay in that directory's CLAUDE.md.

Key concept

Convention follows a file *type* spread across directories → .claude/rules/ glob. Convention bound to one directory → directory CLAUDE.md. Path-scoped rules load only on matching files, saving context and tokens.

What you need to know

How path-scoped rules work

A rule file in .claude/rules/ carries YAML frontmatter with a paths list of glob patterns. The rule loads only when editing a file matching one of those globs — irrelevant rules stay out of context, which saves tokens. A rule with no paths frontmatter loads unconditionally. Globs match by file type regardless of location, so **/*.test.tsx catches every test file no matter which directory it sits in (brace expansion like {ts,tsx} also works).

yaml
---
paths: ["**/*.test.tsx", "**/*.test.ts"]
---
Tests use describe/it blocks. Use data factories, not hardcoded values.
Do not mock the database — use a test database.

Glob rule vs directory CLAUDE.md

The core exam distinction:

  • Glob rule wins when a convention applies to a file type scattered across many directories — for example test files that live beside the components they test (Button.test.tsx next to Button.tsx), or every Terraform file under terraform/**/*. A directory-level CLAUDE.md only applies to its own directory and cannot span the tree.
  • Directory CLAUDE.md wins when the convention is genuinely bound to one part of the codebase — everything under services/api/, say.

Relying on a root CLAUDE.md to *infer* which conventions apply to which files is unreliable, and skills need manual or loaded invocation rather than activating automatically by path. Only a path-scoped rule loads automatically based on the file being edited.

yaml
---
paths: ["terraform/**/*"]
---
Name resources <env>-<service>-<resource>. Always set tags. Pin provider versions.

Why conditional loading matters

Conditional activation is not just tidiness — it is context economy. A monolithic CLAUDE.md that lists testing rules, Terraform rules, and API rules pays for all of them in every session, even when Claude is editing something unrelated. Splitting those into path-scoped rules means the testing rule only loads while editing tests, the Terraform rule only while editing infrastructure, and so on. Less irrelevant context means more room for the actual task and fewer tokens spent.

Exam traps

The trapThe reality
A per-directory CLAUDE.md can enforce test conventions on Button.test.tsx files scattered beside their components.A directory file only covers its own directory. Use a .claude/rules/ file with a **/*.test.tsx glob to catch the type wherever it lives.
The root CLAUDE.md will reliably infer which conventions apply to which files.Inference is unreliable. A path-scoped rule loads deterministically based on the file being edited.
A skill can auto-apply conventions by path the way a rule does.Skills need manual or loaded invocation — they do not activate automatically when you edit a matching file. Only path-scoped rules do.
Path-scoped rules are just an organizational nicety with no runtime effect.They load conditionally, keeping irrelevant conventions out of context and cutting token usage on unrelated edits.

Practice scenario

Real questions from the bank that test this topic — the correct answer is highlighted.

Your team runs Claude Code with a /repo/CLAUDE.md containing testing standards. Last week a junior developer added a section titled "## API Conventions" with detailed REST guidelines and @import @docs/api-style.md . This week your team is reviewing Python files and Claude is suddenly recommending REST-specific changes to Python data classes that have nothing to do with APIs. The junior's API section was added at the very top of CLAUDE.md, pushing the testing standards below. Test files have no path-scoped rules.

AMove the API conventions section to the bottom of CLAUDE.md and put testing standards back on top.
BSplit CLAUDE.md into path-scoped rules under .claude/rules/ : paths: ["/api//*"] for the API conventions, paths: ["**/*.test.*"] for testing.Correct
CRemove the @import directive since it's causing the API rules to be loaded too broadly.
DAdd a system prompt instruction saying "API conventions apply only to API code; Python data classes are not API code."

Why: The junior's mistake exposed a structural weakness in monolithic CLAUDE.md. Path-scoped rules ( .claude/rules/ with paths globs) ensure API conventions only fire for API code, testing standards only for test files. Moving sections around (A) doesn't fix the underlying scope problem.

Your /repo/CLAUDE.md has grown to 1,200 lines covering testing standards, API conventions, deployment procedures, security policies, database conventions, and PR review criteria. Developers complain that updates to one section sometimes affect Claude's behavior on unrelated tasks. Test files are scattered across /repo/services/*/tests/ , /repo/web/ __tests__/ , and /repo/packages/*/test/ .

ASplit CLAUDE.md into multiple files under .claude/rules/ with YAML frontmatter paths glob patterns so each rule file loads only when editing files matching its scope.Correct
BSplit into directory-level CLAUDE.md files in each subdirectory, so each service or package carries its own conventions.
CKeep CLAUDE.md but use @import to reference smaller topic-specific files (testing.md, api-conventions.md), so each can be edited independently.
DMove all rules into a single skill at .claude/skills/conventions/SKILL.md with context: fork , invoked at the start of each work session.

Why: .claude/rules/ with YAML frontmatter paths glob patterns — load only when editing matching files (Task 3.3). B (directory-level) doesn't work for test files scattered across the repo. C (CLAUDE.md @import) still loads everything for every task.

Build exercise

Scope a test convention across scattered test files

~30 min
  1. 1
    Create .claude/rules/testing.md with paths: ["**/*.test.tsx", "**/*.test.ts"] frontmatter and a short set of test conventions.

    Why: The glob targets the file type regardless of which directory each test lives in.

  2. 2
    Scatter a few *.test.tsx files next to their components in different directories.

    You should see: The rule should apply to all of them, not just one directory's worth.

  3. 3
    Edit one of the test files and confirm the testing conventions are in effect.

    You should see: Claude follows the describe/it and data-factory conventions from the rule.

  4. 4
    Edit a non-test file (e.g. a component) and confirm the testing rule does NOT load.

    Why: This demonstrates conditional loading — the rule stays out of context on unrelated edits.

  5. 5
    Add a second rule scoped to terraform/**/* and verify it activates only when editing infrastructure files.

    You should see: Two independent path-scoped rules, each loading only for its own file type.

Sources

Claude Code — Memory & path-scoped rulesClaude Code — Overview

Drill Claude Code Configuration & Workflows

Practice only this domain’s questions, untimed, with instant explanations.