Path-Specific Rules for Conditional Convention Loading

Official Exam Guide Objectives

Knowledge of

• .claude/rules/ files with YAML frontmatter paths fields containing glob patterns for conditional rule activation
• How path-scoped rules load only when editing matching files, reducing irrelevant context and token usage
• The advantage of glob-pattern rules over directory-level CLAUDE.md files for conventions that span multiple directories (e.g., test files spread throughout a codebase)

Skills in

• Creating .claude/rules/ files with YAML frontmatter path scoping (e.g., paths: ["terraform/**/*"]) so rules load only when editing matching files
• Using glob patterns in path-specific rules to apply conventions to files by type regardless of directory location (e.g., **/*.test.tsx for all test files)
• Choosing path-specific rules over subdirectory CLAUDE.md files when conventions must apply to files spread across the codebase

What You Need to Know

Path-specific rules make a convention conditional on what you are editing rather than on where you launched Claude. That closes a gap neither root CLAUDE.md nor a directory-level file covers well: a rule that belongs to a file type which happens to be scattered across the whole tree.

How Path-Specific Rules Work

The files live in .claude/rules/, and each one opens with YAML frontmatter carrying a paths field of glob patterns. Whatever the file says applies only while you are working on files those globs match.

---
paths: ["terraform/**/*"]
---
# Terraform Conventions

- Resource names in snake_case, no exceptions
- Every resource carries environment and owning-team tags
- AMI IDs come from data sources; a hardcoded one is a review blocker
- A module is incomplete without variables.tf, outputs.tf and a README.md

Open a file matching terraform/**/*, and the rules arrive with it. Open a React component or a request handler, and they do not — they stay out of context entirely until the moment they describe the work in front of you.

Glob Patterns Match Across the Entire Codebase

This is the property that makes them worth using. **/*.test.tsx reaches every test file in the repository, no matter how deep or how scattered. A typical layout makes the point:

src/
  components/
    Button.tsx
    Button.test.tsx
  api/
    auth.ts
    auth.test.ts
  utils/
    format.ts
    format.test.ts
  pages/
    dashboard/
      Dashboard.tsx
      Dashboard.test.tsx

Every test sits beside the thing it tests, which puts them in four directories here and rather more in a real project. One rule file declaring paths: ["**/*.test.tsx", "**/*.test.ts"] reaches all of them without knowing where any of them are.

Why Not Directory-Level CLAUDE.md?

Because it reaches one directory. Covering tests spread across 50-odd directories would mean a CLAUDE.md in each of them, which buys you:

• 50-odd copies of one set of conventions
• a new copy to write every time someone adds a directory containing tests
• 50-odd edits every time a convention changes
• copies that fall out of step, because eventually one of those edits gets missed

A single glob replaces all of that, and there is nothing to keep in sync because there is only ever one file.

Why Not Root CLAUDE.md?

Because it loads regardless. Terraform conventions in the root file are in context while you edit React components; test conventions are in context while you write request handlers. Neither is doing anything except consuming budget that the current work needs — and on a project with several convention sets, the ones that are irrelevant will usually outnumber the ones that are not.

Practical Rule File Examples

Test conventions across the entire codebase:

---
paths: ["**/*.test.ts", "**/*.test.tsx", "**/*.spec.ts", "**/*.spec.tsx"]
---
# Test Conventions

- describe/it names should read as sentences describing behaviour
- Every file covers at least one success path and one failure path
- Build test data through factory functions rather than inline literals
- Mock at the module boundary; mocking individual functions couples tests to internals
- Assert on what the code does, never on how it does it

API conventions for any route handler:

---
paths: ["src/api/**/*", "**/routes/**/*", "**/*.controller.ts"]
---
# API Conventions

- Every response takes the shape { data, error, metadata }
- Validate with Zod at the handler boundary, before anything else runs
- Error responses carry the request ID
- State rate limits explicitly; inheriting a default is not a decision

Infrastructure-as-code conventions:

---
paths: ["terraform/**/*", "**/*.tf", "infrastructure/**/*"]
---
# Infrastructure Conventions

- State lives in a remote backend; local state is never committed
- Environments are separated by workspace
- Modules are versioned and carry a CHANGELOG

When to Use Each Approach

The scenario to watch for is tests co-located with the code they cover, across a large tree. It appears repeatedly, and glob-scoped rules are the answer every time — the giveaway is that the files share a naming pattern but no common location.

Deep Dive

The paths frontmatter mechanism, precisely

Rules can be scoped to specific files using YAML frontmatter with a paths field: "these conditional rules only apply when Claude is working with files matching the specified patterns." Rules in .claude/rules/ are discovered recursively, so .md files can be organised into subdirectories as a project grows — .claude/rules/frontend/components.md is discovered the same as a flat file.

Sourcecode.claude.com › memoryfetched 2026-07-30

Glob syntax and brace expansion

paths accepts standard glob patterns (**/*.ts for any TypeScript file at any depth) and brace expansion to match multiple extensions in a single pattern, plus multiple patterns in the same array:

---
paths:
  - "src/**/*.{ts,tsx}"
---

Sourcecode.claude.com › memoryfetched 2026-07-30

Rules without paths frontmatter

A rule file that omits paths entirely isn't conditional — it "is loaded at launch with the same priority as .claude/CLAUDE.md." That's the default for a rules file with no frontmatter at all: always-on, just like the earlier project CLAUDE.md.

Sourcecode.claude.com › memoryfetched 2026-07-30

User-level rules and their priority

Personal rules in ~/.claude/rules/ apply to every project on your machine, exactly the way ~/.claude/CLAUDE.md does. Crucially, "user-level rules are loaded before project rules, giving project rules higher priority" — so when a user-level rule and a project-level rule genuinely conflict, the load order favours the project rule appearing later in context.

Sourcecode.claude.com › memoryfetched 2026-07-30

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Configure Path-Specific Rules with Glob Patterns

Difficulty: Intermediate (2/4)

30 minutes

1. Create .claude/rules/testing.md with YAML frontmatter paths: ["/*.test.ts", "/.test.tsx", "**/.spec.ts"] and test conventions (naming, assertions, mocking patterns)

Why: Path-specific rules with glob patterns are the correct solution for conventions that apply to a file type spread across many directories. The exam favourite scenario is test files co-located with source files across 50+ directories.

You should see: A file at .claude/rules/testing.md with YAML frontmatter containing a paths array with glob patterns. The body contains at least three test conventions covering naming, assertions, and mocking.

2. Create .claude/rules/api-conventions.md with paths: ["src/api//*", "/routes/**/*"] and API conventions (response shape, validation, error handling)

Why: Separating API conventions into their own path-scoped rule means they only load when editing API files. This avoids consuming tokens with irrelevant context when working on frontend or infrastructure code.

You should see: A file at .claude/rules/api-conventions.md with YAML frontmatter paths targeting API directories. The body contains at least three API conventions.

3. Create .claude/rules/terraform.md with paths: ["terraform//*", "/*.tf"] and infrastructure conventions

Why: Infrastructure conventions are completely irrelevant when editing application code. Path-scoped rules ensure Terraform rules never consume tokens during React or API development sessions.

You should see: A file at .claude/rules/terraform.md with YAML frontmatter paths matching Terraform files. The body contains infrastructure-specific conventions.

4. Edit a test file and use /memory to verify that testing rules are loaded but API and Terraform rules are not

Why: This proves the conditional loading mechanism works. The exam tests whether you understand that path-specific rules load only for matching files, and /memory is the diagnostic tool to verify this.

You should see: When editing a .test.ts file, /memory output lists .claude/rules/testing.md as loaded. The .claude/rules/api-conventions.md and .claude/rules/terraform.md files do NOT appear in the /memory output.

5. Edit an API handler and verify that API rules load while testing and Terraform rules do not

Why: This is the complementary verification. Switching contexts should swap which rules are loaded, confirming that the glob patterns correctly scope each rule file.

You should see: When editing a file in src/api/, /memory output lists .claude/rules/api-conventions.md as loaded. The testing and Terraform rule files do NOT appear.

6. Compare the token footprint when all conventions are in root CLAUDE.md versus split into path-specific rules

Why: Token efficiency is a key exam concept. Root CLAUDE.md loads all conventions for every session regardless of relevance. Path-specific rules load only matching conventions, reducing irrelevant context and preserving token budget for actual work.

You should see: With all conventions in root CLAUDE.md, /memory shows the full set of conventions loaded even when editing a simple utility file. With path-specific rules, /memory shows only the relevant subset. The token count for loaded configuration is measurably smaller when using path-specific rules for targeted editing sessions.

Sources

• Claude Code Memory and Rules Documentation — Anthropic
• Claude Certified Architect Foundations Exam Guide — Task Statement 3.3 — Anthropic
• Claude Certified Architect Foundations Exam Guide — Sample Question 6 — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create .claude/rules/testing.md with YAML frontmatter paths: ["/*.test.ts", "/.test.tsx", "**/.spec.ts"] and test conventions (naming, assertions, mocking patterns)

Why: Path-specific rules with glob patterns are the correct solution for conventions that apply to a file type spread across many directories. The exam favourite scenario is test files co-located with source files across 50+ directories.

You should see: A file at .claude/rules/testing.md with YAML frontmatter containing a paths array with glob patterns. The body contains at least three test conventions covering naming, assertions, and mocking.

Create .claude/rules/testing.md:
---
paths: ["**/*.test.ts", "**/*.test.tsx", "**/*.spec.ts"]
---
# Test Conventions

- Use describe/it blocks with descriptive sentence-style names
- Each test must cover at least one happy path and one error case
- Use factory functions for test data, not inline literals
- Mock external services at the module boundary

Step 2. Create .claude/rules/api-conventions.md with paths: ["src/api//*", "/routes/**/*"] and API conventions (response shape, validation, error handling)

Why: Separating API conventions into their own path-scoped rule means they only load when editing API files. This avoids consuming tokens with irrelevant context when working on frontend or infrastructure code.

You should see: A file at .claude/rules/api-conventions.md with YAML frontmatter paths targeting API directories. The body contains at least three API conventions.

Create .claude/rules/api-conventions.md:
---
paths: ["src/api/**/*", "**/routes/**/*"]
---
# API Conventions

- All endpoints return { data, error, metadata } response shape
- Use Zod schemas for request validation at the handler boundary
- Log request ID on every error response
- Rate limiting must be explicit, not inherited from defaults

Step 3. Create .claude/rules/terraform.md with paths: ["terraform//*", "/*.tf"] and infrastructure conventions

Why: Infrastructure conventions are completely irrelevant when editing application code. Path-scoped rules ensure Terraform rules never consume tokens during React or API development sessions.

You should see: A file at .claude/rules/terraform.md with YAML frontmatter paths matching Terraform files. The body contains infrastructure-specific conventions.

Create .claude/rules/terraform.md:
---
paths: ["terraform/**/*", "**/*.tf"]
---
# Infrastructure Conventions

- Use snake_case for all resource names
- Tag every resource with environment and team labels
- Never hardcode AMI IDs — use data sources
- State files must reference remote backends, never local

Step 4. Edit a test file and use /memory to verify that testing rules are loaded but API and Terraform rules are not

Why: This proves the conditional loading mechanism works. The exam tests whether you understand that path-specific rules load only for matching files, and /memory is the diagnostic tool to verify this.

You should see: When editing a .test.ts file, /memory output lists .claude/rules/testing.md as loaded. The .claude/rules/api-conventions.md and .claude/rules/terraform.md files do NOT appear in the /memory output.

Open src/components/Button.test.tsx, then run /memory. Expected output includes:
- .claude/rules/testing.md (loaded)
Should NOT include:
- .claude/rules/api-conventions.md
- .claude/rules/terraform.md

Step 5. Edit an API handler and verify that API rules load while testing and Terraform rules do not

Why: This is the complementary verification. Switching contexts should swap which rules are loaded, confirming that the glob patterns correctly scope each rule file.

You should see: When editing a file in src/api/, /memory output lists .claude/rules/api-conventions.md as loaded. The testing and Terraform rule files do NOT appear.

Open src/api/auth.ts, then run /memory. Expected output includes:
- .claude/rules/api-conventions.md (loaded)
Should NOT include:
- .claude/rules/testing.md
- .claude/rules/terraform.md

Step 6. Compare the token footprint when all conventions are in root CLAUDE.md versus split into path-specific rules

Why: Token efficiency is a key exam concept. Root CLAUDE.md loads all conventions for every session regardless of relevance. Path-specific rules load only matching conventions, reducing irrelevant context and preserving token budget for actual work.

You should see: With all conventions in root CLAUDE.md, /memory shows the full set of conventions loaded even when editing a simple utility file. With path-specific rules, /memory shows only the relevant subset. The token count for loaded configuration is measurably smaller when using path-specific rules for targeted editing sessions.

Test both setups:
1. All in root: add all conventions to .claude/CLAUDE.md, edit a .test.ts file, run /memory — all conventions visible
2. Path-scoped: restore .claude/rules/ files, edit same .test.ts, run /memory — only testing.md visible
The path-scoped setup loads fewer tokens for any given editing context.

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the configuration you wrote for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Config Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the configuration you actually wrote.