AnthropicClaude Certified Architect – Foundations2026-103.3 Apply path-specific rules for conditional convention loading
Centralize conventions that cross directory ownership
Completed by the knowledge check
Learning objective
Prefer path-specific rules over directory-bound CLAUDE.md when convention scope crosses directories.
Core idea
Choose the instruction’s home from the scope of the convention and the team responsible for it. A package’s build and architecture guidance can stay beside that package in a directory CLAUDE.md. A testing convention that applies to files scattered across packages belongs in one .claude/rules/ file with paths selecting those files.
Both mechanisms can defer instructions until relevant work. The reason to prefer a path-scoped rule for dispersed tests is not that directory files always load globally. It is that the convention follows a file pattern across several directory owners. A central rule expresses that shared scope once instead of maintaining copies in every affected folder.
See 3.1.1 for the instruction-file hierarchy, 3.3.1 for conditional loading, and 3.3.2 for glob selection. This lesson uses those mechanisms to choose a maintainable division between repository-wide, directory-owned, and cross-directory guidance.
How it works
Distinguish the instruction’s home from its audience
Anthropic documents per-directory CLAUDE.md files for conventions maintained by directory owners and versioned alongside their code. In a monorepo, that can mean one file per package. In a single application, it can mean one file for src/db/ and another for src/api/.
Path-scoped rules keep the instruction file in central .claude/rules/ while the paths glob selects its audience. Anthropic recommends that choice when you want conventions in one place or when one rule applies to many scattered paths. The rule can therefore select test files under unrelated package directories without requiring a copy in each one.
The following comparison assumes the instruction files are available to the session and have not been excluded:
| Approach | Where the instruction lives | Loading behavior | Suitable convention |
|---|---|---|---|
Project CLAUDE.md | Project root or .claude/CLAUDE.md | Loaded from the working directory and ancestors at launch | Repository-wide guidance |
Directory CLAUDE.md | Beside the directory’s code | Loaded at launch when it is in the working directory or an ancestor, or on demand for descendant file access | Area-specific guidance maintained by its owner |
| Path-scoped rule | .claude/rules/ with paths frontmatter | Loaded when matching file access activates it | Shared guidance that follows file patterns across directories |
A root file with headings for each package still loads those sections together. Headings improve organization; they do not create a file-loading condition. Similarly, moving paragraphs into files imported from root CLAUDE.md with @path changes organization without reducing startup context: the imported files load with the importing file. See 3.1.2 for import mechanics.
Preserve a directory’s useful role
Claude Code loads CLAUDE.md files from the working directory and its ancestors at launch. It loads instruction files below the working directory on demand when Claude reads, writes, or edits another file in that subdirectory. Qualifying Bash reads also count. Starting directly inside a package therefore changes which directory instructions are present from launch.
A directory file is useful when its guidance applies broadly to that area’s code: how the package builds, which local architectural constraints it follows, or which package commands developers should run. Keeping that file beside the code lets the package owner review instruction changes with implementation changes.
It is a poor fit for a convention that applies only to tests distributed through many areas. Copying the same testing paragraph into each directory file gives each owner another version to maintain. It also exposes test-specific guidance when Claude accesses non-test files in those directories. A path-scoped rule can select the test suffix while the directory file supplies local package context.
Do not claim directory files are unable to contain testing guidance. They can, and a package-specific test convention may belong there. The deciding question is whether the instruction belongs to that area’s general context or to a shared file class spanning areas.
Combine shared and local guidance without conflicts
Centralization does not require moving every instruction into .claude/rules/. Keep repository-wide guidance at the root, directory-owned constraints beside their code, and one shared cross-directory rule for the convention that needs that scope. A test can then receive both package context and shared testing guidance.
The two instruction sets must agree. Claude Code concatenates discovered CLAUDE.md files into context rather than treating child files as overriding parents. Anthropic also warns that contradictory instructions can lead Claude to choose one arbitrarily. A deeper directory or a narrower-looking glob is not a reliable override mechanism for conflicting prose.
Review the central rule and local files together when moving a shared convention. Remove redundant copies of that shared instruction while preserving package-specific details. If two packages genuinely require different practices, give their instructions compatible scope and wording rather than declaring one universal convention that neither consistently follows.
Key distinctions and trade-offs
Central file versus global loading: A rule stored centrally can still load conditionally. A convention is not global merely because its instruction file lives at the repository root’s .claude/rules/.
Directory ownership versus scattered file scope: A directory CLAUDE.md keeps broad area guidance with its owners. A path rule follows the selected file class across owners. Choose according to the instruction’s audience, not a preference for one filename.
Path rules versus skills: A path-scoped rule loads when matching files are accessed. A skill loads when you invoke it or Claude determines it is relevant to your prompt. Use the rule when a file-type convention must enter context on matching access; see 3.2.6 for the skill-versus-CLAUDE.md decision.
Organization versus context reduction: Splitting a root file into imported documents helps maintenance but does not defer their loading. paths adds a loading condition; a topic heading or import does not.
One shared rule reduces duplicate text and gives cross-directory changes one review location. Local files preserve area ownership and make package context easy to maintain with the code. Combining the two is useful when shared file-type standards and local architectural constraints must both apply.
Architecture / decision scenario
A developer-productivity team uses Claude Code across packages/web/, packages/api/, and packages/shared/. Test files sit beside production files. Each package’s CLAUDE.md repeats the same test-naming and behavior-coverage guidance, but the copies have drifted. The web package also has its own rendering constraints, while the API package has its own persistence constraints.
The team moves the common testing guidance into .claude/rules/testing.md with paths: ["**/*.test.{ts,tsx}"]. It removes the duplicated common paragraphs from package files and keeps the rendering and persistence guidance with the appropriate directory owners. The root CLAUDE.md retains instructions intended for every task.
When Claude accesses packages/web/Button.test.tsx from a root session, the web directory instructions and matching test rule can both load. Access to packages/api/order.test.ts activates the same shared test convention together with the API context. The selector reaches both packages because it follows the test suffix, not one directory name.
A source-only change to packages/web/Button.tsx does not independently match the test pattern, while the web package’s general guidance remains relevant. A session launched inside packages/api/ loads packages/api/CLAUDE.md and the root CLAUDE.md at launch.
The team checks the remaining package instructions for contradictions with the central test rule. It does not rely on directory depth to settle competing prose. The resulting layout has one place to update the shared convention and retains separate ownership for facts that belong to each package.
Common exam traps
- Copying the same cross-directory convention into every folder that contains a test.
- Assuming every directory
CLAUDE.mdloads at launch from the repository root. - Moving text into root imports and expecting conditional loading.
- Choosing a skill for a file-type convention that must load whenever matching files are opened.
- Treating central storage as equivalent to global scope.
- Removing useful package guidance because shared tests need one central rule.
- Assuming a child instruction file overrides conflicting parent or rule text.
Where the exam guide differs
The exam guide describes path-scoped activation as happening “only when editing matching files.” Claude Code documents matching reads and writes as well as edits, including qualifying Bash reads. The architectural choice is unchanged: prefer a pattern-scoped rule for a convention that spans scattered paths, while testing activation through the broader documented access triggers.
What to remember
Keep directory-owned context beside the code and shared file-pattern conventions in one path-scoped rule. Both can load on demand; their audiences and ownership differ. Root headings and imports organize text without creating conditional scope. Ensure shared and local guidance agrees rather than relying on an assumed override order.
Knowledge check
packages/web/, packages/api/ and packages/shared/ each have a CLAUDE.md that repeats the same test-naming guidance, and the copies have drifted. The web package also holds rendering constraints, and the API package persistence constraints. Tests sit beside production files. Shared test guidance must load on matching file access, and package owners want their broader constraints beside their code. What is the most maintainable layout?
CLAUDE.md and review the copies together each quarter.claude/rules/paths rule and keep package constraints localTo cut startup context, a team splits its large root CLAUDE.md into one file per package and imports each from the root with @packages/<name>/notes.md. Startup context does not shrink. Why?
@path import is expanded and loaded at launch alongside the CLAUDE.md that references it, so splitting a file this way improves organization without deferring anything. A loading condition comes from paths in a rule, or from a directory CLAUDE.md loaded on demand.A repository has a root CLAUDE.md and a CLAUDE.md in each of packages/web/ and packages/api/. A developer launches Claude Code from inside packages/api/. Which of these files are in context at launch?
packages/api/CLAUDE.md , which overrides the root fileCLAUDE.md in the repositorypackages/api/CLAUDE.md and packages/api/CLAUDE.mdCLAUDE.md files from the working directory and its ancestors at launch, concatenating them rather than letting a child override a parent. packages/web/ is neither the working directory nor one of its ancestors, so its file is not part of launch context.References
- Anthropic, Monorepos and large repos
- Anthropic, How Claude remembers your project
- Anthropic, Claude Certified Architect – Foundations Exam Guide