What You Need to Know
Team tooling configuration is every file and setting that shapes Claude's work on shared code. Guidance, such as an instruction file, is context. Enforcement, such as a settings rule or a lifecycle handler, applies no matter what Claude decides. A lifecycle handler, which the documentation calls a hook, makes certain actions always happen. Each element is in a layer, also called a scope. The layer sets who the element applies to.
This lesson uses one made-up example throughout: a supermarket chain. Three developers on its online ordering team each have their own Claude setup. One developer keeps naming conventions in a personal file. Another developer told Claude never to delete order records. A newcomer inherits none of this configuration.
One Question Sorts Everything
Does an element shape output that the team owns collectively? If yes, the element is shared and version-controlled. If no, the element is personal. These elements pass the test:
- project context
- conventions
- standard procedures
- delegated roles
- the tool connections everyone needs
- permitted operations
Editor choice, keybindings and local paths fail the test. Anthropic's guidance names each shared element and commits it to version control. The online ordering team's conventions move into the repository. Keybindings stay personal.
Skipping the question brings gradual divergence rather than chaos. Everyone configures their own, and outputs diverge. Nothing can be improved because nothing is shared. Onboarding a new engineer is the test of the configuration. Whatever a new engineer inherits by cloning, without being told, is the standard. Everything else is a gap.
The Four Layers, and Why Each Exists
The configuration is designed in layers. There are four scopes, each for a different job.
- Organisation-managed: policy that individuals must not override. This layer is at the top of the precedence order (the order that decides which layer's setting wins). So it is the right place for a control that the organisation cannot allow a developer to disable.
- Project-committed: the team's shared standard. The team reviews it in pull requests like any other code, and everyone who clones the repository inherits it.
- Personal: preference that applies to one developer in all their work.
- Local and uncommitted: machine-specific values that must never enter shared history.
The precedence order is reference material. One property decides questions: restrictive rules combine rather than compete. Permission rules merge across scopes instead of overriding each other. So a denial at any layer cannot be undone in another layer. A managed list can be extended but not reduced. A managed control is a minimum that lower layers cannot remove, not a default. If the supermarket chain denies order deletion in the managed layer, no lower layer removes the denial.
Guidance Is Not Enforcement
Written instructions have influence and are worth writing well. They are right for conventions and architectural decisions. They are not an enforced limit. 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 thing 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 an action must never happen, the action needs enforcement, not instruction. The developer's instruction about order records is guidance. A permission rule that denies deletion stops the deletion.
If It Must Never Happen, It Needs Enforcement
When a question says an operation must be prevented, the right answer moves the control into an enforced rule or a lifecycle handler. The wrong option writes the prohibition into the instruction file and calls the operation prevented. Both options name the same rule. Only one option is a mechanism.
What Never Goes in a Shared Layer
Secrets stay out. Anything that is committed is visible to everyone with repository access. It stays in the history after deletion. A credential in a shared layer, such as the supermarket chain's database password, is distributed to the whole organisation. Machine paths and sandbox endpoints (the addresses of test systems) belong in the local uncommitted layer. Better still, automation that needs authenticated access should not hold the credential at all. Anthropic's secure-deployment guidance puts a proxy outside the agent's boundary. The proxy injects the credential.
Bloat, which is unnecessary content, stays out too. Instruction files are context. They add to the cost of every request, whether they are relevant or not. Keep them short and free of contradictions, because two conflicting rules make behaviour arbitrary. Limit narrow instructions to the code that they govern. When a section grows from a fact into a procedure, like the online ordering team's release procedure, package it as a reusable workflow (objective 7.2).
In the exam
Domain 7 has the lightest weighting in the exam guide and is the most predictable on the exam. Every right answer makes proven practice shared and inheritable. It also keeps real enforcement in a place where nobody can override it. The guide publishes no sample here. The objective text names a product, so candidates study product details too much and reasoning too little. No answer depends on a filename. The central idea of the domain is a swap that wrong options make: guidance in place of enforcement. It applies Domain 3's "an instruction is not an access control" and Domain 5's guardrail hierarchy 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 most extreme absolute options in the domain, 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 combine: a denial at any layer stays in force, so no lower scope can remove it. To change a managed denial, ask the administrator whether the policy should change.
Practice Scenario
Four engineers form a new team in a payments monorepo (one repository that holds many projects) 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. One can publish packages to the internal package 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 as a written exercise. 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 shows the gap clearly.
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