Rules under .claude/rules/ can carry frontmatter that scopes them to file paths, so a migration convention only loads when someone touches migrations. Build a set of scoped rules and prove they load conditionally.
What to build
- Create .claude/rules/ with three rule files: one for migrations, one for tests, one for API handlers.
- Give each a paths frontmatter pattern matching only its area.
- Touch a file in each area in turn and observe which rule becomes active.
- Write a fourth rule with no paths key and confirm it applies globally.
- Compare the context cost against putting all four in one CLAUDE.md.
Done when
- Editing a migration surfaces the migration rule and not the test rule.
- The unscoped rule applies everywhere.
- You can articulate why this matters for a large repo's context budget.
- Each rule is specific enough to be actionable, not a general style plea.
The trap this exercise teaches
Scoping by directory name in prose ("when working on migrations…") instead of by the paths key. Prose scoping is a hint; frontmatter scoping is mechanical.
Before you start
The theory behind this build is covered in Path-scoped rules with .claude/rules/. If any step below is unfamiliar, read that first — the exercise assumes it. Primary source: Claude Code Docs — Memory.
Check yourself against the exam
This exercise sits in Domain 2, which is 20% of the CCAR‑F exam. Once you have built it, run a domain drill in the study app and see whether the questions read differently.