D3.1 covered the always-on CLAUDE.md; D3.2 covered the lazy, invocable skill. Rules are the third shape of the instruction layer: modular markdown files that load eagerly like CLAUDE.md, but can be glob-scoped so a rule only enters context when Claude touches the files it governs. The architect’s job here is to know that rules are a separate, equal-priority system, that user and project rules have a load order, and to use path-scoping to keep file-specific guidance out of unrelated work.

A system parallel to CLAUDE.md

.claude/rules/*.md is a modular rules system, loaded into context every session, with recursive discovery across subdirectories. [Official] How Claude remembers your project · AnthropicT1-official original The relationship to CLAUDE.md is the fact to fix first: “Rules without paths frontmatter are loaded at launch with the same priority as .claude/CLAUDE.md.” [Official] How Claude remembers your project · AnthropicT1-official original A rule is not nested under CLAUDE.md or overridden by it — the two are parallel instruction sources discovered separately and loaded at equal priority.

User-level vs project rules — there is a load order

The “no precedence” story needs one refinement the exam can probe: rules come in scopes, and the scopes load in order. User-level rules live in ~/.claude/rules/ and apply to every project on your machine — use them for preferences that aren’t project-specific (your personal style, your workflows). [Official] How Claude remembers your project · AnthropicT1-official original Project rules live in the repo’s .claude/rules/. And the order between them is documented: “user-level rules are loaded before project rules, giving project rules higher priority.” [Official] How Claude remembers your project · AnthropicT1-official original

That is the same recency model as the CLAUDE.md hierarchy (D3.1): files concatenate, but the more-specific scope is read last and so effectively dominates when two instructions tension. So “concatenate, not override” is true within a scope; across scopes there is a load order — user → project, project higher — exactly mirroring CLAUDE.md’s broad-to-specific assembly.

Path-scoping with the paths frontmatter

The lever that makes rules more than “another CLAUDE.md” is the optional paths field. Give a rule a paths glob and it stops loading unconditionally: “path-scoped rules trigger when Claude reads files matching the pattern, not on every tool use.” [Official] How Claude remembers your project · AnthropicT1-official original So a rule scoped to src/api/**/*.ts costs nothing until Claude actually reads an API file — and then applies while that work is in scope.

---
paths:
  - "src/api/**/*.ts"
---

# API Development Rules
- All API endpoints must include input validation

The glob format is the same one skills use for their paths field: [Official] How Claude remembers your project · AnthropicT1-official original

Rules can mix unconditional and path-scoped files in one tree, and discovery recurses into subdirectories:

.claude/
└── rules/
    ├── code-style.md      # no paths: loaded unconditionally
    ├── security.md        # no paths: loaded unconditionally
    ├── frontend/
    │   └── react.md       # paths: src/frontend/**/*.tsx
    └── backend/
        └── api.md         # paths: src/api/**/*.ts

The unconditional files (code-style.md, security.md) are always in context; the nested path-scoped files wait for a matching file-read. [Official] How Claude remembers your project · AnthropicT1-official original Rules can also be shared from a central directory by symlink: “symlinks work in .claude/rules/ — link shared rules from a central dir; circular symlinks are detected gracefully.” [Official] How Claude remembers your project · AnthropicT1-official original

Choosing the shape: rule vs CLAUDE.md vs skill

The three instruction shapes now in view divide cleanly by when they load and what they carry:

The practical rule of thumb: reach for a paths-scoped rule when guidance is real but only relevant to part of the tree — it is the one shape that lets you write file-specific instructions without paying for them on every unrelated turn.

Practice

Exercise solutions

Solution ↑ Exercise

C. A path-scoped rule is exactly this case: with paths: ["src/api/**/*.ts"] the standard loads only when Claude reads a matching API file, and stays out of context otherwise. A and B both load the line unconditionally — CLAUDE.md and an un-scoped rule sit in context at the same priority every session, which is the clutter you wanted to avoid. D misuses a skill: skills are invocable capabilities/workflows, not standing rules that should bind automatically while editing a file. The lever that matters is paths, and only a rule (or a skill) offers it — so the rule is the right shape for a standing, file-scoped instruction.

Solution ↑ Exercise

src/**/*.{ts,tsx} — or, to cover the whole repo regardless of directory, **/*.{ts,tsx}. A single paths entry with brace expansion {ts,tsx} matches both extensions; ** matches any directory depth. (You can also list two patterns, but the brace form does it in one.)

Solution ↑ Exercise

Claude favors 2-space indent — the project rule wins. Your preferences.md is a user-level rule (~/.claude/rules/, applies to every project); the repo’s code-style.md is a project rule. The documented order is that user-level rules load before project rules, giving project rules higher priority — so when both are in context and they tension, the project rule (read last) dominates. Your personal preference acts as a default that any project can override for its own repo.

Exam essentials