7.1 Configuring Claude Code for Teams

Picture a single developer, working alone, setting up Claude Code exactly the way they like it: their own shorthand for commit messages, a couple of personal aliases, maybe a quick permission tweak so it stops asking before running tests. None of this causes a problem, because there's no one else to be inconsistent with. Now multiply that developer by forty, spread across a dozen repos, and ask the same question an architect has to ask: does everyone's Claude Code behave the same way when it touches the same codebase?

Left alone, the answer is no. One developer's Claude Code allows a shell tool another developer's blocks. One repo has rich project context; a near-identical repo two folders over has none, because whoever set it up never wrote it down anywhere shared. A new hire joins, clones the repo, and gets a completely different experience than the person sitting next to them who's been on the team for two years. That's not a Claude Code problem so much as an onboarding and configuration-management problem — and it's exactly the problem Task Statement 7.1 asks an architect to solve.

The fix isn't one setting or one file. It's recognizing that Claude Code actually gives you two different kinds of configuration, built for two different jobs, and a handful of distribution mechanisms for sharing capability team-wide. Get the two kinds straight and the rest of this lesson — the CLAUDE.md hierarchy, settings.json, shared MCP servers, team Skills — is really just working out where each piece of team knowledge belongs.

CLAUDE.md is the persistent memory you write once and Claude reads at the start of every session — the standing instructions and context a new collaborator would want to read before touching your codebase. But CLAUDE.md files don't live in just one place. They form a hierarchy, and which level you write at decides who receives your instructions. This is the single most-tested distinction in the whole domain, because it's so easy to write something true and useful in the wrong place and have it quietly never reach the team.

At the top sits enterprise/system-level memory, managed centrally by an organization for org-wide policy. Below that is user-level memory (~/.claude), which is personal: it applies across every project a given developer touches, but it lives on their machine and is never checked into any repository. Below that is project-level memory (./CLAUDE.md), which lives inside the repo itself — committed, version-controlled, and pulled down by everyone who clones it. And below that, a subdirectory can hold its own CLAUDE.md, scoping instructions to just that part of the codebase. All of these are auto-loaded into context; none of them require the developer to remember to do anything.

Here's the decision an architect actually has to make over and over: a piece of team knowledge exists — "we always run the integration suite before merging," "this service's retry logic follows pattern X" — and someone has written it down. If they wrote it in their personal ~/.claude/CLAUDE.md, it helps exactly one person. The team-standardization move is to take that knowledge and put it in the project-level CLAUDE.md, committed to the repo, so it reaches every developer the moment they clone. That's the whole idea: the project-level file is not just "a" place to put instructions, it's THE place for anything the whole team needs, precisely because it travels with the code itself rather than with any one person's machine.

CLAUDE.md answers "what should Claude know and remember?" A completely different question is "what is Claude actually allowed to do, no matter what it decides?" That second question belongs to a different file entirely: settings.json. And confusing the two is the single most common misconfiguration this domain tests.

settings.json is the deterministic control surface for a team's Claude Code deployment. It holds the tool allow/deny lists that decide which commands Claude may run without asking, the hooks that fire automatically at fixed lifecycle points, environment variables, model selection, and the connected MCP servers a session can reach. None of that is advisory. Where CLAUDE.md is delivered to Claude as ordinary context — something it reads and tries to follow, with no guarantee of strict compliance — settings.json is enforced by the harness itself, independent of anything the model decides. If a rule needs to hold every single time, settings.json (or a hook wired through it) is where it has to live.

So when a permission rule shows up written in prose inside CLAUDE.md — "never delete files without asking" — recognize it for what it is: a hint the model will usually follow, not a guarantee. The moment that instruction actually matters (a production database, a force-push, a refund above some threshold), it needs to be an allow/deny rule or a hook in settings.json, enforced regardless of what the model concludes. This is the same model-proposes/code-disposes principle that runs through the whole certification, just applied to team-wide configuration instead of a single agent's tool call.

settings.json doesn't only govern which tools an agent may call -- it's also where an architect enforces SPEND POSTURE: the deliberate set of controls that decide how much a team can spend, on which models, and how much reasoning depth they default to. Left unconfigured, spend posture defaults to "whatever any individual developer's session happens to invoke," which is exactly the same per-developer drift problem 7.1.2 already named for memory and 7.1.4 (below) names for integrations -- just applied to cost instead of context or capability.

This is the same enforced-vs-advisory distinction 7.1.3 already established for permissions, now applied to cost. A sentence in CLAUDE.md -- "please use the cheaper model for routine tasks" -- is advisory context Claude tries to follow; it offers no guarantee, and a developer, or the model reasoning about an unusual request, can simply not follow it. A model allowlist or a hard spend cap enforced in settings.json holds regardless of what any session decides, the same way a PreToolUse hook holds regardless of what the model "decided" about a destructive action. Spend governance isn't a new category of architectural concern -- it's the identical deterministic-vs-probabilistic split from 7.1.3 showing up on a different axis.

Now suppose the team knowledge in question isn't an instruction at all, but a capability — "Claude Code should be able to look up customer records in our internal CRM." How should forty developers get that ability? The naive answer is: each developer configures the integration themselves, in their own settings. It works, technically. It's also exactly the anti-pattern the exam wants you to recognize.

Configuring the same integration forty separate times means forty separate places that can drift out of sync. When the CRM API changes its auth flow, or credentials rotate, or an endpoint moves, someone has to track down and fix every individual developer's configuration — rather than one shared configuration everyone already points at. The architect's answer is a shared MCP server: configure the integration once, register it centrally (through settings.json, as you saw above), and every developer's Claude Code reaches the same capability automatically. This is build-once, reuse-across-the-team — the identical philosophy behind shared tooling in integration design, just applied to how a team, rather than a single agent, gets its capabilities.

It's worth noticing why this generalizes so cleanly. An MCP server is, structurally, just a description of tools plus a connection to run them — which means "configure it once, everyone gets it" isn't a special MCP feature, it's a natural consequence of MCP servers being config, not code baked into any one developer's prompts or scripts. Centralize the config, and you've centralized the capability.

There's a third kind of team knowledge that isn't an instruction (CLAUDE.md) or a capability (an MCP server) — it's a procedure. "How our team debugs a stuck payment job." "How our team formats a release PR." "The five checks our team always runs before touching the pricing service." That kind of know-how usually lives in one senior engineer's head, or scattered across old Slack threads, and every new developer has to rediscover it the hard way, usually right after breaking something.

Skills are how Claude Code packages that kind of reusable procedure into something Claude can actually draw on. And just like CLAUDE.md and MCP servers, a Skill only becomes a team asset once it's distributed at the team level rather than kept on one developer's machine: via repos, plugins, or enterprise managed settings. Written that way, "how we debug a stuck payment job" stops being tribal knowledge locked in one person's memory and becomes something every developer's Claude Code can invoke, the same way, every time.

Notice the pattern repeating across this entire lesson: CLAUDE.md hierarchy, settings.json, MCP servers, Skills — four different mechanisms, but every single one follows the same underlying discipline. Centralize the configuration or the know-how at the team level, put it under version control or managed distribution, and stop relying on any individual developer's personal setup to carry something the whole team needs. That's the throughline an architect brings to Task Statement 7.1: not memorizing four separate features, but recognizing the one principle they all express.

Everything else in this lesson -- CLAUDE.md, settings.json, shared MCP servers, spend posture, team Skills -- assumes the team is actually going to use Claude Code once it's configured correctly. That's not automatic. An architect who gets every configuration surface right can still watch adoption fail, because rolling a new tool out to an organization is its own design problem, with its own well-understood failure modes, separate from getting the tool itself configured correctly.

The pattern that avoids the most common failure modes is: designate ONE CHAMPION per department or team, who receives deep onboarding first -- real hands-on time, real use cases from their own work, enough depth to become genuinely fluent rather than just aware. That champion then runs PEER-TO-PEER adoption sessions for their own team, in small batches, rather than the organization defaulting to a single company-wide training blast that gives everyone the same shallow hour and calls it done. A company-wide session is usually run by someone from outside the team, using generic examples, to an audience with wildly different daily workflows -- a backend engineer and a frontend engineer get the identical generic demo, neither sees their own real workflow addressed, and most of the room mentally checks out within the first fifteen minutes. A champion who already knows the team's actual codebase and actual daily friction can make the same hour concretely relevant to the six or eight people in the room.

Consider a 60-person engineering org split into three teams: Platform (22 engineers), Product (25 engineers), and Data (13 engineers). Rather than one all-hands training session, the rollout looks like this: in week 1, one champion per team (3 people total) gets a half-day, hands-on onboarding session run by the architect directly, working through that champion's own team's real recent pull requests and real recurring pain points, not generic examples. Across weeks 2 through 4, each champion runs three 90-minute peer sessions with their own team, in batches of 7-8 people -- Platform runs three batches of about 7, Product runs three batches of about 8, Data runs two batches of 6-7 -- small enough that everyone in the room gets hands-on time with their own real code, not a lecture. In week 5, champions reconvene with the architect to compare what worked, what stalled, and which agentic or Skill-based workflows their teams actually adopted versus which landed flat -- feeding directly into what CLAUDE.md conventions and team Skills get written up next. By week 5, all 60 engineers have had genuine hands-on exposure to real work in their own codebase, delivered by someone who already had credibility on that team, rather than sixty people who sat through one generic 45-minute demo in week 1 and never opened Claude Code again.

You now have the full map: CLAUDE.md's hierarchy and its user-vs-project scoping, settings.json as the enforced control surface (including spend posture), shared MCP servers for capability, team Skills for procedure, and the champion-per-department pattern for making sure a well-configured setup actually gets adopted rather than sitting unused. The fastest way to make this stick is to actually audit a setup and sort what you find into the right bucket -- because on the exam, that's exactly the move: read a scenario, identify which mechanism is being misused or missing, and pick the fix.

With team-wide configuration settled, the next question is what a team actually DOES with a well-configured Claude Code — how the interactive gather-context-plan-act-verify loop scales into automated pipelines, and what happens when something in that pipeline breaks. That's Lesson 7.2, and it starts from the same discipline you've just learned to protect here: guardrails first, leverage second.