What You Need to Know
Team tooling configuration is every file and setting shaping Claude's work on shared code. Guidance, like an instruction file, is context. Enforcement, like a settings rule or lifecycle handler, applies whatever Claude decides. Each element sits in a layer, or scope, setting who it reaches.
A craft shop's three developers each have their own Claude setup. One keeps naming conventions in a personal file. Another told Claude never to delete order records. A newcomer inherits none of it.
One Question Sorts Everything
Does an element shape output the team collectively owns? If yes, it is shared and version-controlled. If no, it is personal. These pass:
- project context
- conventions
- standard procedures
- delegated roles
- the tool connections everyone needs
- permitted operations
Editor choice, keybindings and local paths fail. Anthropic's guidance commits each shared surface to version control by name. The craft shop's conventions move into the repository; keybindings stay personal.
Skipping the question brings gradual divergence rather than chaos: everyone configures their own, outputs drift apart, and nothing can be improved because nothing is shared. Onboarding is the acceptance test. Whatever a new engineer inherits by cloning, untold, is the standard. Everything else is a gap.
The Four Layers, and Why Each Exists
The layering is the design: four scopes, each for a different job.
- Organisation-managed: policy individuals must not override. It sits at the top of the precedence order, which makes it the right home for a control the organisation cannot allow a developer to switch off.
- Project-committed: the team's shared standard, reviewed in pull requests like any other code and inherited by everyone who clones.
- Personal: preference that follows one developer across all their work.
- Local and uncommitted: machine-specific values that must never enter shared history.
The precedence order is lookup material. One property decides questions: restrictive rules compose rather than compete. Permission rules merge across scopes instead of overriding, so a denial at any layer cannot be undone elsewhere. A managed list can be extended but not reduced. A managed control is a floor, not a default. If the craft shop denies order deletion in the managed layer, no lower layer lifts it.
Guidance Is Not Enforcement
Written instructions are influential, worth writing well, and right for conventions and architectural decisions. They are not a boundary. As documented: "Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer." The permissions guidance says the same independently. The hooks guidance supplies the mechanism: lifecycle handlers give "deterministic control: certain actions always happen rather than relying on the LLM to choose to run them". If it must never happen, it needs enforcement, not instruction. The craft shop's note is guidance; a permission rule denying deletion stops it.
If It Must Never Happen, It Needs Enforcement
When a stem says an operation must be prevented, the keyed answer moves the control into an enforced rule or a lifecycle handler. The distractor writes the prohibition into the instruction file and calls it prevented. Both name the same rule; only one is a mechanism.
What Never Goes in a Shared Layer
Secrets stay out. Anything committed is visible to everyone with repository access and stays in history after deletion. A credential there, like the craft shop's database password, is distributed to the whole organisation. Machine paths and sandbox endpoints belong in the local uncommitted layer. Better still, automation needing authenticated access should not hold the credential at all. Anthropic's secure-deployment guidance puts a proxy outside the agent's boundary to inject it.
Bloat stays out too. Instruction files are context, paid for on every request whether relevant or not. Keep them short and free of contradictions, because two conflicting rules make behaviour arbitrary. Scope narrow instructions to the code they govern. When a section grows from a fact into a procedure, like the craft shop's stock-take routine, package it as a reusable workflow (objective 7.2).
In the exam
Domain 7 has the blueprint's lightest weighting and is the most predictable on the exam. Every keyed answer makes proven practice shared and inheritable, and keeps real enforcement where it cannot be argued with. The guide publishes no sample here. The objective text names a product, so candidates over-prepare mechanics and under-prepare reasoning. Nothing turns on a filename. The domain's spine is the planted substitution of guidance for enforcement. It is Domain 3's "an instruction is not an access control" and Domain 5's guardrail hierarchy, arriving in the developer's own environment.
Exam Traps
Writing a prohibition into the shared instruction file and treating the operation as prevented
Instructions shape what the agent tries to do without changing what the client allows. Anything that must never happen needs an enforced rule or a lifecycle handler. The sentence can stay; it is not the mechanism.
Offering an onboarding page, wiki or training session as the answer to divergent setups
A page depends on every individual reproducing it correctly and re-reading it whenever it changes. Committed configuration is inherited on clone, reviewed in pull requests, and improves for everyone when one person improves it.
Restricting the tooling to senior engineers, or requiring a human to retype every generated change
The domain's loudest absolutes, and both are wrong. They discard the tool while keeping its risks and substitute a person for a control. Enforced limits and independent review cover senior engineers too.
Assuming a permission granted at one scope widens what another scope forbids
Restrictive rules compose: a denial at any layer stands. The same reasoning catches layer mismatches, such as organisation policy placed where a team can change it, or a standard placed where nobody inherits it.
Practice Scenario
Four engineers form a new team in a payments monorepo where two other teams already use AI-assisted tooling daily. They inherited nothing: each wrote a private description of the codebase and no two agree, and one can publish to the internal registry with no review. What should the architect put in place?
Build Exercise
Write the Configuration Map for One Team
What you'll learn
- How to sort a team setup into shared and personal elements
- How to assign each element to the layer that fits it
- How to separate operations needing enforcement from conventions needing guidance
- How to keep credentials and machine values out of shared history
- How to test a configuration against a new engineer onboarding
- Take a team you work with, or design one of ten engineers, and list every element of its Claude tooling setup: context, conventions, procedures, delegated roles, tool connections, permitted operations, credentials, machine paths
Why: The map starts from what exists, and most setups are larger and more private than their owners remember.
You should see: One flat list, including whatever one person set up once and nobody has looked at since.
- Assign each element to one layer - organisation-managed, project-committed, personal, or local-uncommitted - and write one sentence on why that layer and not the one above it
Why: The layer is decided by who must not be able to override the element, not by who happened to configure it.
You should see: Every element in one layer, justified by naming who must not be able to change it.
- Write the enforcement list: every operation that must be prevented regardless of what the model decides, the mechanism that prevents it, and a flag against any relying on a written instruction
Why: This is the domain signature judgement, and the flagged rows are the real findings.
You should see: A short list of must-never operations, each with a mechanism, and an honest count of how many are guidance today.
- Name anything in a shared layer that would be visible to everyone with repository access, and say how it would instead be scoped, short-lived and injected at the point of use
Why: Anything committed is distributed to the whole organisation and stays in history after deletion.
You should see: A list of exposures with a replacement pattern for each, and machine values moved to the uncommitted layer.
- Run the onboarding test on paper. A new engineer clones the repository and starts work: list what they inherit automatically, and what still requires a person to tell them
Why: Onboarding is the acceptance test for the configuration, and the second list is the gap in plain sight.
You should see: Two lists, the first holding conventions, context and permitted operations, the second as short as you can honestly make it.
Sources
- How Claude remembers your project — Anthropic
- Configure permissions — Anthropic
- Automate actions with hooks — Anthropic
- Securely deploying AI agents — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 7 — Anthropic