← Domain 2: Applications and Integration

2.6 · 4.1% of the exam · Topic 6 of 6

Configuration Management

Shared behavior lives in project configuration. CLAUDE.md is guidance and files are concatenated. settings.json is where a rule is enforced. Model ids, prompts, and plugin versions are pinned so a change is a reviewable diff.

Learning objectives

Put team instructions in project CLAUDE.md and personal instructions in the user file.
Treat CLAUDE.md files as concatenated context, not as a precedence chain.
Put a rule that must hold every time in settings.json or a hook, not only in CLAUDE.md.
Pin the model id and version the prompt next to the code that sends them.
Declare plugin dependencies so a clone gets the same capability.

Detailed theory

What this skill covers

Configuration management is 4.1% of the exam. The published list is CLAUDE.md files, settings.json, model version pinning, prompt versioning, and plugin dependencies.

This repository's Claude Code lessons already establish the file behavior. User-level ~/.claude/CLAUDE.md is personal and is not in git. Project CLAUDE.md, at the root or under .claude/, is what a clone receives. Applicable CLAUDE.md files are concatenated into context. A more specific file does not replace a broader one. settings.json has a real precedence chain, managed policy over local, project, and user. CLAUDE.md does not.

CLAUDE.md and settings.json

Use project CLAUDE.md for commands, layout, and conventions the whole team follows. Use the user file for preferences that should not ship. If a teammate clones the repo and does not see a convention, the convention was on one machine.

settings.json is enforced by the client: permissions, models available to the product, and other controls that do not depend on the model agreeing. A prohibition that is only written in CLAUDE.md can be ignored, because the file is additional text. The architect lesson in this repo states the settings order as managed policy, then local, then project, then user.

Pins, prompts, and plugins

Public notes say to pin a model version in production and to treat an upgrade as a change that needs evaluation. An alias that silently tracks the newest release skips that evaluation. The pin is configuration. The evaluation is the life cycle in 2.2.

Prompt versioning means the text the application sends is in version control with an identity you can deploy and revert. Editing a prompt in a host's panel without a commit leaves the running behavior outside the repository.

Plugin dependencies are the same idea. If the design needs a plugin, the project configuration names it and a version. A plugin present only under one home directory is personal configuration, and a clone will not have it.

Core concepts

Project CLAUDE.md

What: Instructions committed with the repository.
Why: A clone should receive the team's conventions.
When: Commands, layout, and review rules everyone follows.
When not: A personal preference, or a rule that must be enforced even when the model ignores text.

User CLAUDE.md

What: Instructions in the home directory, not in git.
Why: They must not become the team's undocumented standard.
When: Something only you want.
When not: A convention a new teammate is expected to follow.

settings.json

What: Client configuration with precedence. This repo's lesson order is managed, local, project, then user.
Why: Enforcement does not depend on the model reading a paragraph.
When: Permissions and other controls that must hold.
When not: You are explaining a coding style. That can live in CLAUDE.md.

Pin and version

What: A model id and a prompt text that change only through review.
Why: Both change behavior without a compile error.
When: Production and any shared environment.
When not: A local experiment that is not the team's running configuration.

Plugin dependency

What: A named, versioned plugin the project expects.
Why: Capability that exists on one laptop is not part of the shared system.
When: The surface is Claude Code or Desktop and the workflow needs that plugin.
When not: The plugin is a personal experiment. Leave it in user configuration.

Practical examples

The convention that did not clone

One developer gets the API naming rules on every edit. A teammate who cloned yesterday does not. The rules are in ~/.claude/CLAUDE.md. User files are not in the repository, so the clone never received them. Project CLAUDE.md is the file that travels. This is the scenario already taught in this repository's CLAUDE.md hierarchy lesson.

A floating model alias

Production calls an alias that moves when the vendor ships a new model. Quality shifts and the git diff of the application is empty. Pin the id that was evaluated. A later move to a new id is a configuration change with a review, not an invisible bump.

Claude-specific considerations

CLAUDE.md concatenation is not settings precedence. Do not answer a conflict in two CLAUDE.md files by saying the more specific file wins.
On the Messages API there is no CLAUDE.md. The system prompt you send is the instruction configuration, and it still needs a version in git.
A hook or a permission in settings can block a tool. A sentence in CLAUDE.md cannot guarantee that block.
Plugin versions drift the way libraries drift. Record the version the team tested.

Architecture decisions

SituationChooseBecause

The whole team must see a convention after clone.Project CLAUDE.md.User configuration stays on one machine.

A tool must not run, every time.settings.json or a hook.CLAUDE.md is context, not a gate.

Two CLAUDE.md files disagree.Rewrite them so they do not depend on a winner.They are concatenated. More specific does not replace the other.

Production should keep today's behavior.Pin the model id.A floating alias can change without a diff.

The prompt was edited in a hosting panel.Move it into the repository and deploy that version.Otherwise there is nothing to review or revert.

A workflow needs a plugin.Declare it in project configuration with a version.A personal install is not a team dependency.

Tradeoffs

CLAUDE.md is easy to edit and easy for the model to miss. settings.json is narrower and actually applied. A pin is slightly less convenient than an alias and is the version you evaluated.

AxisConvenienceA version you can explain

InstructionsA user file, present on one machine.Project CLAUDE.md, present after clone.

EnforcementA prohibition written only as guidance.settings.json or a hook.

ModelAn alias that tracks the newest release.A pinned id, upgraded on purpose.

Prompt and pluginsEdited in a panel or installed by hand.Committed and versioned with the project.

Quick reference

Project CLAUDE.md is shared. User CLAUDE.md is not.
CLAUDE.md files are concatenated. They do not override each other.
settings.json has precedence. This repo's lesson order is managed, local, project, user.
A must-hold rule is settings or a hook. CLAUDE.md is guidance.
Pin the model id. Version the prompt in git.
A required plugin is a project dependency with a version.

Decision rules for the exam

If the question says…The answer is likely…

"clone does not see the convention"It is in user CLAUDE.md. Move it to the project

"the inner CLAUDE.md should replace the root"They are concatenated

"the push must never happen"settings.json or a hook, not only CLAUDE.md

"quality changed and git is clean"The model alias or the prompt is unpinned

"works with the plugin on my laptop"Declare the plugin for the team

Common exam traps

TrapCorrect answer

More specific CLAUDE.md wins.Files are combined. There is no single winner.

A clear sentence in CLAUDE.md blocks a tool.Enforcement is settings or a hook.

Team rules in ~/.claude/CLAUDE.md.A clone never receives that file.

A floating model alias in production.Pin the id you evaluated.

Open the Domain 2 sheet

Exam tips

The CLAUDE.md facts above are already in this repository's hierarchy lesson. No separate Developer Domain 2 question set is stored here.
Do not import the architect mock items tagged as tool design. Those are not this skill.
If the stem says the rule failed open, look for guidance where a gate was required.

Common mistakes

Storing a token in CLAUDE.md so the team can see it.
The file is shared text. Name an environment variable. Do not commit the secret.
Expecting the API service to load CLAUDE.md.
Send the versioned system prompt yourself.
Pinning the model in code and editing the prompt only in production.
Both are configuration. Both need a version.

Practice questions

Original questions for this topic. They are study items, not questions from the live exam.

Scenario questions

Build exercise

Separate guidance, enforcement, and pins

Beginner · 30 minutes

What you will learn

Which file a clone receives.
What concatenation implies when two files disagree.
Where a hard prohibition goes.
What to pin besides the model.

Step 1
List five rules from a real or imagined service
Include a naming convention, a personal editor preference, a tool that must never run, a model id, and a plugin the team needs.
Why: The skill is placement, and the five rules want five different homes.
You should see: Five lines.
Step 2
Assign each rule a file
Project CLAUDE.md, user CLAUDE.md, settings or a hook, a pinned model id in the repo, or a plugin dependency.
Why: Putting all five in CLAUDE.md is the mistake.
You should see: The prohibition is not in CLAUDE.md. The convention is not in the home directory.
Step 3
Write the conflict
Add a second CLAUDE.md sentence that contradicts the naming rule. State what concatenation does.
Why: The more-specific-file story is the common error.
You should see: A sentence that says both files are in context.
Step 4
Name the versions
Write the model id and the prompt path you would put in a pull request, and the plugin version.
Why: Pinning is configuration management, not only a code comment.
You should see: Three names a reviewer could revert.

Review checklist

Checks are saved in this browser.

I put shared conventions in project CLAUDE.md.
I do not expect one CLAUDE.md to replace another.
I put hard rules in settings.json or a hook.
I pin model ids and version prompts.
I declare plugin versions the team depends on.
I keep secrets out of committed configuration.

Key takeaways

Project files travel with the clone. User files do not.
CLAUDE.md is concatenated guidance. settings.json enforces.
Model ids, prompts, and plugins are versioned configuration.
An API service does not load CLAUDE.md. It sends the prompt you versioned.

Sources

CCDV-F exam guide, Domain 2 skill weights — Public blueprint summary: CLAUDE.md, settings.json, model version pinning, prompt versioning, plugin dependencies.
CLAUDE.md hierarchy lesson — Existing lesson in this app for file scope and settings precedence

Domain 2 overview · Quick reference

View progress