Claude Code configuration: CLAUDE.md, Skills and hooks as the exams test them

Claude Code configuration is examined as a set of judgments, not as syntax. The published task statements cover instruction-file hierarchy and scoping, custom commands and Skills, rules that load by path, plan mode against direct execution, iterative refinement, and running inside CI. The line running through all six is the same: an instruction shapes behaviour, and only an enforcement point guarantees it. Choosing correctly between those two is what the items reward.

Where claude code configuration is actually assessed

Two tracks examine it and they weight it very differently. On Architect Foundations it is a whole domain at 20% — about twelve of sixty questions, and the third-heaviest domain on that paper. On Developer Foundations the Claude Code domain is 3.1%, which is roughly two questions out of fifty-three.

That asymmetry catches people out in a specific way. Developers reach for this material first because it is what they work in every day, and on their own exam it is worth two marks. If you are sitting the developer track, read this once and spend the time you saved on Applications and Integration, which is a third of that paper. The full domain weights for all four exams make the trade obvious.

The six published task statements for the architect domain, and what each is really asking:

Two of those lean on measurement rather than configuration: iterative refinement is only a technique if the improvement can be shown, which needs a baseline and a threshold fixed in advance.

An instruction file is context, not configuration

This is the misconception the domain is built around. An instruction file is not a settings file that the system reads and obeys. It is loaded into the model's context, where every line competes for attention with every other line and with the task itself. It shapes behaviour reliably. It does not bind it.

The practical consequence is that these files get worse as they get longer. A file that grows by one rule after every incident eventually holds so many competing instructions that some are followed inconsistently — including, sooner or later, the rule that would have caught the next incident. Length is not a free variable here, and “we wrote it down” is not the same as “it will happen”.

The levels compound rather than replace. Broader files and narrower ones are combined, so a rule written for one team's corner of a repository is still occupying attention on unrelated work.

Scope a rule to what it governs

Rules that apply to one part of a codebase can be attached to that part, so they load when the work touches it and cost nothing when it does not. That is the whole purpose of conditional loading, and it is a published task statement in its own right.

The examinable judgment runs in both directions. A convention that only ever applies inside one part of the tree should live there, not in a shared file carrying a note about when it is relevant — the note does not stop the rule being loaded for every other task. But a requirement that genuinely applies everywhere must not be scoped to somewhere for tidiness, because that quietly narrows its coverage. A scope is a claim about where a rule holds, not a filing decision.

Personal preferences have their own level for the same reason. A formatting habit that binds one person's sessions is a personal setting. Promote it to the shared file and it becomes a team standard that colleagues must read, evaluate and then choose to disregard.

Guidance, or a guarantee

This distinction appears across every domain on the architect exams, and it is at its clearest here. Some mechanisms describe what should happen. Others prevent what must not. Where a scenario uses words like “never”, “always” or “without exception”, the option that expresses the rule as an instruction is the distractor, however well written it is.

The same logic decides where a check belongs. A formatting step that should run after every edit is not a paragraph asking for it; a destructive command that must be refused is not a warning about it. Each is a point in the loop where the action can be inspected or refused before it happens. That is the difference between a system property and a habit.

Plan mode is a judgment, not a safety blanket

Deciding between planning first and simply starting is its own published task statement, which means the exam expects you to argue both directions. A plan is worth its delay in three situations: the route is disputed, the surface is wide enough that getting the scope wrong is costly to undo, or the work rests on something nobody has pinned down yet — there, naming the unknown before implementation is the whole benefit.

It is not worth it on a routine change where the route is not in doubt. There a plan records a decision nobody was contesting and pushes the work back; “for rigour” is not an argument. Wanting a written record of the approach is a different problem, and it has cheaper solutions than pausing the work.

When nobody is watching, the question changes

Running inside a pipeline is the last of the six statements, and it shifts every earlier judgment. Interactive work has a person who can approve an unexpected action; automated work does not. What is permitted therefore has to be decided up front rather than resolved as it comes up, and anything that would pause for an answer simply halts instead.

Two ideas recur in items about this. First, verify in proportion to how little you watched: a session you followed needs a glance, and an unattended run needs a reconstructed check from what it left behind — which is easier when the run has been keeping a durable record of its own findings. Second, removing prompts is not the same as removing protection — the mode that answers approvals for you is not the mode that skips the checks entirely, and reaching for the second because the first is inconvenient is a recognisable wrong answer.

For how this material sits next to the tool and integration domains, see Model Context Protocol explained, and for the architecture decision that comes before any of it, when not to build an agent. If you have not chosen a track, the certification comparison guide is the place to start. Official outlines for each track are published on the Anthropic Partner Academy certification pages.

Key takeaways

• Check the weight before you invest. This is 20% of Architect Foundations and 3.1% of Developer Foundations — about twelve questions against about two.
• Instruction files are context, not configuration. They compete for attention, so a longer file is a weaker one, and writing a rule down does not make it hold.
• The levels combine rather than override. A rule scoped to one area still costs attention everywhere unless it is attached to the paths it governs.
• “Never” and “always” are enforcement words. When a scenario uses them, the instruction-shaped option is the distractor.
• Plan mode is defended both ways. Contested approach or broad surface, yes; a small change with one obvious route, no.
• Unattended runs need settled permissions and a reconstructed check. Fewer prompts is not the same as fewer safeguards.