Rubric
Contents — domains, guide and mocks

Path-specific rules

CCAR-F 3.312 min read · checked 21 September 2026

Task statementApply path-specific rules for conditional convention loading

When a path-scoped rule loads

  1. Session startsonly unscoped rules and CLAUDE.md load
  2. Claude reads a filee.g. src/api/users.ts
  3. Glob checkdoes it match any rule’s paths?
  4. Rule joins contextapi.md conventions now apply
Rules without paths load at launch like the project CLAUDE.md. Rules with paths wait until Claude reads a file that matches one of their globs.

What a rule file is

Rules are Markdown files in a project’s .claude/rules/ directory, one topic per file with a descriptive name such as testing.md or api-design.md. Files are discovered recursively, so you can group them in folders like frontend/ and backend/. They are committed with the repository, so the whole team gets them.

A rule with no frontmatter loads at session start with the same priority as .claude/CLAUDE.md — it is simply a way to split a long CLAUDE.md into topic files. Add a paths field in YAML frontmatter and the rule becomes conditional: it loads only when Claude works with files that match one of its glob patterns.

.claude/rules/api.mdmarkdown
---
paths:
  - "src/api/**/*.ts"
---

# API development rules

- Validate every request body with the shared zod schemas
- Return errors in the standard { code, message } shape
- Add an OpenAPI comment to each new endpoint

Writing the globs

The paths value is a list of glob patterns. ** matches any number of directories, * matches within one path segment, and braces expand to alternatives. Quote each pattern in the YAML. You can list several patterns in one rule, and a brace group such as {ts,tsx} covers several extensions in one line.

PatternMatches
**/*.tsEvery TypeScript file, in any directory
src/**/*Everything under src/
*.mdMarkdown files in the project root only
src/components/*.tsxComponents directly in that folder, not in subfolders
src/**/*.{ts,tsx}TypeScript and TSX anywhere under src/
**/*.test.tsEvery test file, wherever it lives

Checking files against paths: ["src/api/**/*.ts"]

  • Passes: src/api/users.ts** can match zero folders
  • Passes: src/api/v2/billing/invoices.tsany depth under src/api/
  • Fails: src/api/users.test.tsx.tsx is not .ts
  • Fails: lib/api/users.tswrong top-level folder
  • Fails: src/apis/users.tsapis is not api
** crosses any number of folders, but the pattern still needs the src/api/ prefix and the .ts extension.

Rules or per-directory CLAUDE.md?

Both target part of the tree, and both load on demand. The difference is where the file lives and what it can match. A subdirectory CLAUDE.md can only describe files inside its own folder. A rule lives centrally in .claude/rules/ and can match any glob — including files scattered all over the codebase.

Two ways to scope a convention

Per-directory CLAUDE.md

  • Lives beside the code, e.g. packages/api/CLAUDE.md
  • Covers only files inside that folder
  • Loads when Claude reads a file there, or at launch if started there
  • Good when a folder’s owners maintain their own conventions

Path-scoped rule

  • Lives centrally in .claude/rules/
  • Matches any glob, e.g. **/*.test.ts
  • Loads when Claude reads a matching file
  • Good for conventions that cut across folders

Personal, shared and debugging

  • User-level rules. ~/.claude/rules/ applies to every project on your machine. These load before project rules, so project rules take priority.
  • Sharing across repositories. .claude/rules/ supports symlinks to a shared folder. A link that points outside the working directory is treated like an external import and needs approval — and even then, only its rules without paths load.
  • Excluding. claudeMdExcludes in settings can skip another team’s rules directory by glob, just as it skips their CLAUDE.md files (see 3.1).
  • Skills can be path-scoped too. A skill’s paths frontmatter makes Claude load it automatically only for matching files — useful when the guidance is a procedure rather than a short rule (see 3.2).
  • Debugging. /context lists loaded rules under Memory files. The InstructionsLoaded hook fires whenever a CLAUDE.md or rule file loads, with a load_reason such as path_glob_match; it is informational and cannot block loading.

Where should this convention go?

Which files need this guidance?
  • Every file, every session
    Root CLAUDE.mdor an unscoped rule
  • Files in one folder
    Folder CLAUDE.mdor a rule scoped to that folder
  • A pattern across folders
    Path-scoped rulee.g. **/*.test.ts
  • A long procedure
    Skilloptionally with paths

Traps the wrong answers are built from

Tempting but wrongDo this instead
Putting file-type conventions in the root CLAUDE.mdMove them into .claude/rules/ with paths so they load only for matching files.
Copying the same CLAUDE.md into every folder that has testsWrite one rule scoped with a glob such as **/*.test.ts.
Splitting CLAUDE.md into rule files without paths and expecting context savingsUnscoped rules load at launch like CLAUDE.md; add paths to make them conditional.
Writing src/api/*.ts when handlers live in nested foldersUse ** (e.g. src/api/**/*.ts) to match any depth.
Putting a hard guarantee in a path-scoped ruleRules are guidance like CLAUDE.md; use hooks or permission rules to enforce.

You should now be able to

  • Create a rule in .claude/rules/ and scope it with paths frontmatter.
  • Write glob patterns that match exactly the intended files, including ** and brace groups.
  • Explain that scoped rules load when Claude reads a matching file, and unscoped rules load at launch.
  • Choose between a path-scoped rule, a per-directory CLAUDE.md and a skill for a given convention.
  • Confirm a rule loaded with /context or the InstructionsLoaded hook.

Practice questions

Original questions written for this lesson, in the exam’s style. Answer first, then open the reasoning — every option is explained, including why the wrong ones are tempting.

  1. Question 1

    A logistics company keeps React components in web/src/components/ and its GraphQL resolvers in server/src/resolvers/. Each has its own detailed conventions, currently all in a 450-line root CLAUDE.md.

    Which approach best loads each set of conventions only when relevant?

    1. ASplit the root file into two @imports, one per area.
    2. BCreate two rules in .claude/rules/, each with a paths glob for its area.
    3. CMove both sets into ~/.claude/CLAUDE.md so they load last.
    4. DAdd “only apply this section to components” headings in CLAUDE.md.
    Show answer and reasoning
    1. AIncorrect. Imports help organisation but load at launch, so every session still carries both sets.
    2. BCorrect. Scoped rules load only when Claude reads a matching file, so frontend sessions never carry resolver rules and vice versa.
    3. CIncorrect. Load order doesn’t reduce cost, and the user file isn’t shared with the team.
    4. DIncorrect. The text still loads in every session; headings don’t make instructions conditional.

  2. Question 2

    A fintech team writes a rule with paths: ["src/payments/*.ts"]. Claude follows it when editing src/payments/refund.ts, but ignores it when working on src/payments/providers/stripe.ts.

    What is the fix?

    1. AMove the rule’s content into src/payments/providers/CLAUDE.md as well.
    2. BRemove the paths field so the rule loads everywhere.
    3. CChange the pattern to src/payments/**/*.ts.
    4. DRename the rule file to payments.md so it matches the folder.
    Show answer and reasoning
    1. AIncorrect. Duplicating guidance invites drift; the glob itself is what needs fixing.
    2. BIncorrect. This makes it load in every session, giving up the conditional loading the team wanted.
    3. CCorrect. A single * doesn’t cross folder boundaries; ** matches providers/ and any deeper nesting.
    4. DIncorrect. The file name is for people; matching is done by the paths globs.

  3. Question 3

    A university’s research-software team wants conventions for database migration files, which live in db/migrations/ in six different services across the repository.

    Which two statements are correct? (Select 2.)

    1. AOne rule with paths: ["**/db/migrations/**"] covers all six services.
    2. BThe rule will load at session start in every session because it lives in .claude/rules/.
    3. CThe rule loads when Claude reads a file that matches the pattern.
    4. DPath-scoped rules are enforced, so Claude cannot edit a merged migration.
    5. EThe rule must be copied into each service’s own .claude/rules/ to work.
    Show answer and reasoning
    1. ACorrect. ** at the start matches the migrations folder wherever it sits, so one central rule serves every service.
    2. BIncorrect. Only rules without paths load at launch; a scoped rule waits for a matching file.
    3. CCorrect. That is the documented trigger for path-scoped rules.
    4. DIncorrect. Rules are guidance in context; enforcement needs a hook or a permission deny rule.
    5. EIncorrect. A central rule with a leading ** already matches in every service.

  4. Question 4

    A rule file in .claude/rules/style.md has no frontmatter at all. When does it load?

    1. AOnly when Claude reads a Markdown file.
    2. BNever, because rules require a paths field.
    3. COnly when a user invokes it with /style.
    4. DAt session start, like .claude/CLAUDE.md.
    Show answer and reasoning
    1. AIncorrect. Without paths there is no pattern to match; the file’s own extension is irrelevant.
    2. BIncorrect. paths is optional; unscoped rules are a supported way to split instructions.
    3. CIncorrect. That describes a skill or command, not a rule.
    4. DCorrect. Rules without paths load unconditionally at launch with the same priority as .claude/CLAUDE.md.

Practise every question in Domain 3 →

Sources

Drafted with AI assistance and checked against the sources above; expert review is in progress. Spotted an error? Tell us and it gets fixed, dated and listed on how this is written.