- In short
- Convention application scenario analysis is the skill of choosing the right Claude Code mechanism for a given convention: a path-specific rule for files scattered across the repo by type, a directory-level CLAUDE.md for a single package, a root CLAUDE.md for universal standards, or a skill for an on-demand workflow that should not sit in context all the time.
The four mechanisms behind Claude Code convention loading
Claude code convention loading is, at the highest level, a single decision with four answers. When you have a convention you want Claude to follow, you must place it where it will load at the right time and for the right files. Get this right and Claude applies the convention precisely; get it wrong and the convention either fails to appear when needed or clutters every session with instructions that do not apply. This knowledge point is assessed at the evaluate level, the top of task statement 3.3, because it asks you to weigh a scenario against all four options and justify the best fit rather than recall a single rule.
The four mechanisms are a path-specific rule in .claude/rules/, a directory-level CLAUDE.md, the root CLAUDE.md, and a skill. Each has a different loading behaviour, and the analysis turns on matching that behaviour to the convention. The earlier knowledge points in this task statement each isolated one piece of this, the rule mechanics, the glob-versus-directory comparison, the token cost. Here those pieces combine into a judgement call, so the work is comparative: name what each option would do in the scenario, then choose.
- Convention application scenario analysis
- Evaluating a scenario to decide which Claude Code mechanism should carry a convention. The choice is among a path-specific rule (files scattered by type), a directory-level CLAUDE.md (one package), a root CLAUDE.md (universal standards), and a skill (an on-demand workflow that should not occupy context all the time).
A decision framework for Claude Code convention loading
Two questions resolve almost every scenario. First, how are the governed files distributed? If they share a type but are scattered across the tree, that points to a path-specific rule with a glob. If they are concentrated in one package or folder, that points to a directory CLAUDE.md. If the convention applies to everything, it belongs in the root CLAUDE.md, which loads in full every session. Second, should the convention always be in context, or only sometimes? A standing convention Claude should apply automatically while editing belongs in a rule or a CLAUDE.md. A multi-step procedure that only matters when you choose to run it belongs in a skill, which loads on demand.
Put concretely, the mapping reads like this. Test conventions for .test files spread across fifty directories: a path-specific rule with "**/*.test.*". PCI logging standards for the payments package only: a directory CLAUDE.md in that package. Universal build commands and repo architecture every session needs: the root CLAUDE.md. An on-demand release checklist or review routine: a skill, invoked when wanted. The art is reading the scenario for those two signals, distribution and timing, and letting them select the mechanism.
Why skills sit apart: always-loaded versus on-demand
The cleanest way to misjudge a scenario is to forget that rules and CLAUDE.md are always-on context while skills are on-demand. Rules without a paths field, and every CLAUDE.md in scope, load into context as standing instructions Claude carries as it works. A skill is different: its body loads only when it is invoked or when Claude judges it relevant to your prompt, so long reference material in a skill costs almost nothing until you actually use it. That difference is decisive for procedures. A code-review routine or a deployment checklist is not a convention Claude should silently apply to every edit; it is a workflow you trigger at a moment of your choosing.
This is exactly why putting a review workflow into CLAUDE.md or an unconditional rule is the classic wrong answer. It forces a multi-step procedure into every session's context, where it both wastes the budget and risks Claude half-applying it at the wrong time. Move it to a skill and it stays dormant until invoked, which is what a procedure wants. Conversely, putting a genuine always-apply standard, "use 2-space indentation," into a skill is the opposite mistake: the standard would only take effect on the rare occasions the skill is loaded, when it should be governing every file all the time.
Worked example
A platform team brings you four conventions to wire into Claude Code. (1) Test files named *.test.tsx, sitting beside components across 60+ directories, must follow one assertion style. (2) The billing package has strict money-handling and audit-logging rules that apply nowhere else. (3) The whole repo must use the team's commit-message format and run the lint command before commits. (4) There is a detailed, eight-step incident-response runbook engineers should execute only when an outage is declared. Classify each.
Take them one at a time, applying the two questions, distribution and timing.
Convention 1 is a standing convention whose files share a type (.test.tsx) but are scattered across sixty-plus directories. Distribution says "scattered by type," so this is a path-specific rule: .claude/rules/testing.md with paths: ["**/*.test.tsx"]. A directory CLAUDE.md would need sixty copies; the root CLAUDE.md would load test rules during non-test work. The glob rule is correct.
Convention 2 is a standing convention concentrated in one package. Distribution says "one folder," so this is a directory-level CLAUDE.md in the billing package, where money-handling and audit rules load on demand when Claude touches that subtree and reach nothing outside it. Forcing these into the root CLAUDE.md would impose billing-specific rules on every unrelated session.
Convention 3 is a standing convention that applies to everything: commit format and the pre-commit lint command are universal. That is the root CLAUDE.md's job, since it loads in full every session and these facts are needed every session. (If "run lint before every commit" must be guaranteed rather than merely encouraged, the stronger tool is a hook, but as a convention it lives in the root CLAUDE.md.)
Convention 4 is not a standing convention at all; it is an on-demand procedure. The runbook should run only when an outage is declared, not sit in context shaping every edit. Timing says "on demand," so this is a skill, invoked when an incident starts. Putting an eight-step runbook into CLAUDE.md or an unconditional rule would bloat every session with steps that are almost never relevant.
Four conventions, four different mechanisms, each chosen by reading distribution and timing. That comparative justification, not just the final label, is what an evaluate-level answer must supply.
What makes the exercise genuinely evaluative is that several of the wrong answers are individually defensible. The root CLAUDE.md would deliver the test rules, the directory CLAUDE.md would hold the billing rules well, and you could cram the runbook into a rule. None of those are absurd in isolation; they are wrong only relative to a better fit. So the analysis is not about eliminating nonsense, it is about ranking plausible options against the two axes and explaining why the chosen one dominates. A learner who can only recognise the obviously-bad answer will stumble on the version of the question where every option is at least coherent; the one who reasons from distribution and timing arrives at the same answer every time.
Common judgement errors to avoid
The two errors below are the ones that most reliably separate a correct evaluate-level answer from a plausible-sounding wrong one.
Misconception
A repeatable code-review or deployment workflow belongs in CLAUDE.md or an always-on rule so Claude always knows the steps.
What's actually true
Misconception
Conventions that apply only to one file type are best placed in the root CLAUDE.md so they are never missed.
What's actually true
Where hooks and settings fit the bigger picture
The four mechanisms in this framework all carry advisory context: CLAUDE.md, rules, and skills shape what Claude does, but Claude treats them as guidance rather than enforced configuration. For a top-level evaluate question that distinction can be the whole answer, because some scenarios are not really about convention loading at all. When a requirement must hold every time with zero exceptions, run lint before every commit, never write to a protected directory, the right tool is a hook, which executes as a deterministic script at a fixed lifecycle event regardless of what Claude decides. And when an organisation must hard-block a tool or command across every session, that belongs in managed settings, not in any CLAUDE.md.
Reading a scenario well therefore sometimes means recognising that the best answer is outside the four convention mechanisms entirely. A convention says "Claude should usually do X"; a hook says "X will happen no matter what." Mistaking a must-enforce requirement for a convention, and parking it in CLAUDE.md where it is merely encouraged, is the same class of error as parking a procedure in an always-on rule. The evaluate-level skill is matching the strength of the requirement, advisory versus enforced, as carefully as you match its distribution and timing.
Progressive disclosure: how a skill stays cheap until invoked
It is worth understanding why a skill can hold a long procedure yet cost almost nothing until used, because that mechanism is what makes it the right home for an on-demand workflow. Skills load by progressive disclosure. At session start, only each skill's metadata, its name and a one-line description, is preloaded, just enough for Claude to know the skill exists and when it might apply. The body of SKILL.md is read only when the skill becomes relevant to what you are doing, and any secondary files it references, a REFERENCE.md or an EXAMPLES.md, are lazy-loaded only as they are needed.
That layered model is the technical backing for the timing axis in the framework above. A rule without a paths field and every in-scope CLAUDE.md load in full at launch, so their entire text occupies context from the first token; a skill exposes only a label until invoked. It also sets an authoring expectation: keep the top-level SKILL.md tight, since once loaded it competes with conversation history for the budget like anything else. When you evaluate a scenario and the convention is really an invoked procedure, progressive disclosure is the reason a skill, not an always-on rule, keeps that procedure out of every unrelated session.
A second pass: re-checking your placement
Choosing a mechanism is not a one-time act, because conventions drift as a codebase grows. The official guidance is to review CLAUDE.md files, nested CLAUDE.md files, and .claude/rules/ periodically and prune anything outdated or conflicting, since two instructions that disagree leave Claude to pick one arbitrarily. A second pass is where you catch a "convention" that has quietly turned into a multi-step procedure and should migrate to a skill, a directory CLAUDE.md whose package was refactored out of existence, or a glob that no longer matches the files it was written for. Treating placement as something you re-evaluate, rather than set once, is what keeps the four-way decision sound over time, and it is exactly the kind of judgement the capstone knowledge point of this task statement is asking you to demonstrate.
How this shows up on the exam
As the evaluate-level capstone of task statement 3.3, this knowledge point presents multi-part scenarios, often a list of conventions like the worked example, and asks you to assign the correct mechanism to each, or to judge whether a proposed placement is sound. The discriminators are the two framework questions. Watch for the distribution signal (scattered by type, concentrated in a package, or universal) to choose among the rule and the two CLAUDE.md scopes, and watch for the timing signal (always-on versus on-demand) to decide whether something is a convention at all or actually a skill. The traps are predictable: a workflow dressed up as a convention that belongs in a skill, and a type-specific standard pushed into the root CLAUDE.md where it over-loads. A strong answer states why each option fits or fails, because at this level the reasoning is the assessment.
A team wants Claude Code to run a consistent, seven-step security-review procedure, but only when an engineer explicitly asks for a review before merging. They are about to paste the seven steps into the root CLAUDE.md so 'Claude always has them.' Evaluating this plan, what is the best recommendation?
People also ask
When should I use a skill instead of a rule in Claude Code?
Should coding standards go in CLAUDE.md or .claude/rules?
When do I use a root CLAUDE.md vs a directory CLAUDE.md?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Claude Code best practices | Code w/ Claude
Why watch: Anthropic's own best-practices talk shows how to structure CLAUDE.md, rules, and skills, giving learners the authoritative basis for choosing the right convention mechanism per scenario.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.