Path-Specific Rules for CCA-F

Path-specific rules solve a deceptively common Claude Code problem: an instruction matters for some files, but loading it for the entire repository is unnecessary or harmful. That decision sits directly inside the configuration domain of the Claude Certified Architect – Foundations exam.

The site’s existing CCA-F identifier maps to the credential Anthropic now documents under the official exam code CCAR-F.

The exam is less interested in the existence of a rules directory than in the reason to use one. Candidates need to distinguish conventions that follow a file pattern from conventions that follow a directory, and both from instructions that should be present in every session.

Start with the question: what should trigger this instruction?

Suppose a repository contains TypeScript services, Terraform infrastructure, generated clients, and SQL migrations. A root instruction saying “follow Terraform naming rules” is irrelevant while Claude edits application code. Loading it anyway consumes context and can make the agent overgeneralize infrastructure conventions into places where they do not belong.

A path-specific rule makes the condition explicit. The rule activates when Claude works with matching files, so the instruction travels with the kind of work that needs it rather than with every conversation in the repository.

That trigger model is the key exam idea. If the convention follows file type or a pattern spread across the codebase, conditional rules are usually a stronger fit than a directory-specific instruction file.

Understand the role of paths and glob patterns

Path-scoped rules use path patterns to express where guidance applies. A rule can target Terraform files wherever they appear, tests across multiple packages, migrations in several services, or another cross-cutting set of files that does not map cleanly to one directory.

The practical challenge is writing patterns that are broad enough to catch the intended files and narrow enough to avoid unrelated ones. A rule that silently matches nothing is just as dangerous as a rule that matches the entire repository. Test the pattern against the actual tree rather than assuming it is correct.

For exam questions, phrases such as “all test files regardless of directory” or “every Terraform file across the monorepo” are strong clues that the convention follows a pattern rather than a single subtree.

Know when a nested CLAUDE.md is the better answer

A directory-level instruction file is a better fit when the rule belongs to one package and everything beneath it. Imagine a payments service with its own architecture, test harness, and deployment conventions. If the instruction is really about that subsystem, tying it to the directory is simpler than inventing a global glob pattern.

This is a scope distinction, not a competition between features. Path-specific rules are ideal for cross-cutting file patterns. Nested project instructions are ideal when the directory itself is the boundary.

The exam often makes both answers plausible. Choose based on what defines applicability: the location in the tree or the kind of file being edited.

Conditional loading protects the context window

The purpose of conditional loading is not decorative organization. It keeps irrelevant instructions out of context until they are needed. That becomes increasingly important in large repositories where architecture notes, testing conventions, data rules, and infrastructure standards can easily outgrow the useful default context.

Reducing irrelevant material also improves clarity. Claude has fewer competing instructions to reconcile, and developers can reason about why a particular rule was active for a particular edit.

This is why simply splitting a large root file into several imports does not solve the same problem. Modular imports may improve maintenance, but if they all load every time, the context cost remains. Conditional rules solve a different problem.

Keep rules descriptive rather than encyclopedic

A path-specific rule should describe the conventions that genuinely matter for that slice of the codebase. If it turns into a full tutorial, it will consume context every time a matching file is touched. Link to concise internal references or split the rule when different concerns have different triggers.

Good rules are also specific enough to verify. “Write secure Terraform” is vague. “Use the approved module, require encryption, and keep public ingress disabled unless the service exception is documented” tells the agent what the project actually expects.

The same editorial principle applies to human documentation: write the rule because the team needs it, not because the configuration system can hold it.

Do not confuse conditional guidance with enforcement

A path-specific rule still operates as model-facing guidance. It can strongly shape behavior, but it is not the same as a mechanism that blocks a forbidden command or rejects an invalid change. If a requirement must never be bypassed, enforce it with a deterministic layer such as permissions, hooks, tests, or policy tooling.

That distinction matters because path scoping can feel like a security boundary. It is not. Matching a secret-file path and telling Claude not to read it is weaker than a permission rule that makes the read impossible.

CCA-F scenarios repeatedly test the difference between helping the model make a good decision and building a system that guarantees a constraint. Path-specific rules belong to the first category.

Practice with a mixed repository

Create a small repository containing application code, tests, Terraform, and generated files. Give each category one real convention. Put a global instruction at project scope, a package-specific rule in a nested directory, and a file-type convention in a path-specific rule.

Then deliberately break the mapping. Put the test rule at project scope and notice how often it becomes irrelevant. Put a Terraform convention in a nested folder even though Terraform files exist in several packages. These mistakes make the correct selection logic memorable.

When you can explain why a rule follows a pattern, why another follows a directory, and why a third belongs everywhere, you understand the architectural distinction the exam is looking for.

Debug rules by checking applicability before content

When a path-specific convention appears to be ignored, start by asking whether the rule actually matched the file. Developers often jump straight to rewriting the instruction when the real problem is the path pattern, repository layout, or assumption about when the rule loads. A perfect instruction that never activates has no effect.

Inspect the target paths with concrete examples. If the rule is intended for every test file, collect examples from different packages and verify that the pattern reaches each one. If it is intended only for infrastructure code, confirm that similar filenames elsewhere do not match accidentally. Testing scope is part of testing the rule.

Once applicability is correct, then review the instruction itself. Keep it concrete, avoid contradictory requirements, and separate mandatory project conventions from advice that Claude may apply differently depending on context. Debugging in this order avoids changing two variables at once.

This makes a useful exam heuristic: before assuming the model ignored a rule, ask whether the rule was in context at all. Configuration problems often masquerade as reasoning problems.

Use path scoping to support large monorepos

Monorepos make the value of conditional rules especially visible. A single repository may contain web applications, mobile clients, infrastructure code, data pipelines, internal tooling, and generated artifacts. One global instruction file cannot describe all of them precisely without becoming enormous.

Path-specific rules let teams attach the right conventions to the right classes of files even when those files are scattered across several packages. A testing rule can follow test filenames, an infrastructure rule can follow Terraform paths, and generated-code guidance can activate only where generated files appear.

That approach also makes ownership clearer. Security engineers can maintain rules for sensitive infrastructure patterns, while application teams maintain their own package guidance. The repository becomes a set of intentional scopes instead of one undifferentiated instruction blob.

For CCA-F preparation, imagine how each rule would behave as the repository doubles in size. The strongest solution is usually the one whose scope remains correct without requiring every team to copy the same instruction into many directories.

Path rules also benefit from naming conventions that make ownership obvious. A file called `testing.md` or `terraform-security.md` communicates intent better than a generic `rules2.md`. Clear names help humans audit the rule set and make it easier to notice when two files are trying to govern the same behavior.

As a repository evolves, periodically sample files from each major area and ask which instructions should be active. This is the configuration equivalent of a test suite. If a new package appears outside an old glob, the audit catches the missing scope before developers discover inconsistent behavior during a critical change.

Be cautious with patterns that accidentally include generated or vendored code. Guidance intended for source files can produce noisy suggestions when applied to artifacts the team does not edit. A precise exclusion or narrower pattern protects both context quality and developer attention.

The same reasoning applies when a repository contains multiple languages. A cross-cutting security rule may need to load for several extensions, while language-specific formatting rules should remain separate. Conditional loading works best when each rule has one coherent reason to activate.

On the exam, the strongest answer usually makes the condition explicit and minimizes irrelevant context. If the proposed solution causes unrelated work to carry instructions it cannot use, look for a narrower scope.