Study guides / CCAR-F / Domain 3

Claude Code Configuration & Workflows · Lesson 3 of 6

3.3 - Path-Specific Rules for Conditional Convention Loading

Master path-specific rules in .claude/rules/ with YAML frontmatter glob patterns for conditional convention loading, token efficiency, and cross-directory coverage

Path-specific rules apply conventions conditionally, based on which files you're editing. They solve something neither root CLAUDE.md nor directory-level CLAUDE.md handles well: conventions that must apply to one file type scattered across many directories.

How Path-Specific Rules Work

Rule files live in the .claude/rules/ directory. Each file carries YAML frontmatter with a paths field specifying glob patterns. The rules inside load only when you're editing files that match those patterns.

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

- Use snake_case for all resource names
- Tag every resource with environment and team labels
- Never hardcode AMI IDs - use data sources
- All modules must have a variables.tf, outputs.tf, and README.md

Edit a file matching terraform/**/* and these rules load automatically. Edit a React component or an API handler and they don't. The rules stay invisible until they're relevant.

Glob Patterns Match Across the Entire Codebase

This is where they earn their keep. A glob like **/*.test.tsx catches every test file in the codebase, wherever it sits. Take a typical project structure:

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

Test files sit next to their source files across four directories. A path-specific rule with paths: ["**/*.test.tsx", "**/*.test.ts"] applies the same test conventions to every one of them, automatically.

Why Not Directory-Level CLAUDE.md?

A directory-level CLAUDE.md applies to files in that one directory. To cover test files spread across 50+ directories, you'd have to drop a CLAUDE.md into every single directory that holds tests. That means:

Path-specific rules with glob patterns eliminate this entirely. One file, one pattern, universal coverage.

Why Not Root CLAUDE.md?

Root CLAUDE.md loads for every session, regardless of which files you edit. Put your Terraform conventions in the root CLAUDE.md and they burn tokens even while you're editing React components. Put your test conventions there and they load while you're writing API handlers.

Key Concept

Path-scoped rules are more token-efficient than root CLAUDE.md because they load ONLY when editing matching files. This reduces irrelevant context and keeps the model focused on conventions that actually apply to the current work. In large projects with many convention categories, this efficiency gain is substantial.

Practical Rule File Examples

Test conventions across the entire codebase:

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

- Use describe/it blocks with descriptive names that read as sentences
- Each test file must have at least one happy path and one error case
- Use factory functions for test data, not inline object literals
- Mock external services at the module boundary, not individual functions
- Assert behaviour, not implementation details

API conventions for any route handler:

---
paths: ["src/api/**/*", "**/routes/**/*", "**/*.controller.ts"]
---
# 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 configuration must be explicit, not inherited from defaults

Infrastructure-as-code conventions:

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

- State files must reference remote backends, never local
- Use workspaces for environment separation
- Every module must be versioned with a CHANGELOG

When to Use Each Approach

Scenario Best approach
Universal team standards that apply to all code Root CLAUDE.md
Conventions for one specific package directory Directory-level CLAUDE.md
Conventions for a file type spread across many directories Path-specific rules with glob patterns
Task-specific workflows invoked on demand Skills in .claude/skills/

The exam frequently presents the scenario of test files co-located with source files across many directories. The answer is always path-specific rules with glob patterns.

Exam traps

Practice question

A codebase has test files co-located with source files throughout 50+ directories (e.g., Button.test.tsx next to Button.tsx). The team wants all tests to follow the same conventions regardless of location. What is the most maintainable approach?

  • A Create a rule file in .claude/rules/ with YAML frontmatter paths: ["**/*.test.tsx", "**/*.test.ts"] holding the test conventions for the repo Correct

    Glob patterns in .claude/rules/ match files by pattern across the entire codebase. The conventions load automatically when editing any test file, regardless of directory. One file covers all 50+ directories with zero maintenance as new test files are added.

  • B Place a CLAUDE.md file in every directory that contains test files, each carrying a copy of the team test conventions

    With 50+ directories, this creates massive duplication. Every convention change requires updating 50+ files. New directories need new copies. Drift is inevitable.

  • C Add all the test conventions to the root CLAUDE.md file so they are loaded into context for every session

    Root CLAUDE.md loads for every session. Test conventions would consume tokens even when editing non-test files. Path-specific rules are more token-efficient.

  • D Create a skill in .claude/skills/ that includes the test conventions and instruct developers to invoke it before writing or editing any tests

    This approach relies on developers remembering to invoke the skill for every test edit - human discipline is the weak link. Skills can also auto-activate via a paths frontmatter, but even then they load on-demand as a task-style workflow rather than as always-in-context guidance. Test conventions should shape every edit to a matching file, which is exactly what .claude/rules/ with path scoping provides - automatic context-level loading with no human step.

Build exercise: Configure Path-Specific Rules with Glob Patterns

Intermediate · 30 minutes

You'll practice:

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

    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.

    Hints
    1. Rule files in .claude/rules/ use YAML frontmatter between --- delimiters to specify which file paths trigger loading.
    2. The paths field is a YAML array of glob patterns. Use ** to match across directory levels and * to match filenames.
    3. 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
  2. Create .claude/rules/api-conventions.md with paths: ["src/api/**/*", "**/routes/**/*"] and API conventions (response shape, validation, error handling)

    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.

    Hints
    1. Use directory-based glob patterns to target API-related paths across the codebase.
    2. Combine multiple patterns to catch API handlers in different directory structures: src/api/ and any routes/ directory.
    3. 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
  3. Create .claude/rules/terraform.md with paths: ["terraform/**/*", "**/*.tf"] and infrastructure conventions

    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.

    Hints
    1. Target both the terraform directory and any .tf file extension to catch infrastructure code wherever it lives.
    2. Use two patterns: one for the terraform directory tree and one for .tf files anywhere in the codebase.
    3. 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
  4. Edit a test file and use /context to verify that testing rules are loaded but API and Terraform rules are not

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

    You should see: When editing a .test.ts file, /context 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 /context output.

    Hints
    1. Open any file ending in .test.ts or .test.tsx and then run /context to check which rules are active.
    2. Create or open a file like src/utils/format.test.ts, then run /context. Look for testing.md in the loaded files list. Confirm api-conventions.md and terraform.md are absent.
    3. Open src/components/Button.test.tsx, then run /context. Expected output includes:
      - .claude/rules/testing.md (loaded)
      Should NOT include:
      - .claude/rules/api-conventions.md
      - .claude/rules/terraform.md
  5. Edit an API handler and verify that API rules load while testing and Terraform rules do not

    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/, /context output lists .claude/rules/api-conventions.md as loaded. The testing and Terraform rule files do NOT appear.

    Hints
    1. Switch to editing a file inside src/api/ or a routes directory and run /context again.
    2. Open src/api/auth.ts and run /context. The api-conventions.md should now appear. Testing and Terraform rules should not.
    3. Open src/api/auth.ts, then run /context. Expected output includes:
      - .claude/rules/api-conventions.md (loaded)
      Should NOT include:
      - .claude/rules/testing.md
      - .claude/rules/terraform.md
  6. Compare the token footprint when all conventions are in root CLAUDE.md versus split into path-specific rules

    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, /context shows the full set of conventions loaded even when editing a simple utility file. With path-specific rules, /context shows only the relevant subset. The token count for loaded configuration is measurably smaller when using path-specific rules for targeted editing sessions.

    Hints
    1. Temporarily move all conventions into root CLAUDE.md and check /context while editing a test file. Then restore path-specific rules and compare.
    2. Put all three rule sets (testing, API, Terraform) into the root CLAUDE.md. Run /context while editing a test file - all conventions load. Then split them back into .claude/rules/ with path scoping. Run /context again - only testing conventions load.
    3. Test both setups:
      1. All in root: add all conventions to .claude/CLAUDE.md, edit a .test.ts file, run /context - all conventions visible
      2. Path-scoped: restore .claude/rules/ files, edit same .test.ts, run /context - only testing.md visible
      The path-scoped setup loads fewer tokens for any given editing context.

Sources