How Anthropic Teams Use Claude Code
The thing that makes Claude Code work across a team is not a clever prompt; it is a handful of shared rules that live next to the code. A team convention is a durable rule, file, or review habit that tells Claude Code how work gets done in one repository and tells the rest of us what still needs a human look. , and it gets a lot more useful the moment its context stops living in one person's chat history.
As of June 16, 2026, the official Claude Code changelog records version 2.1.179. A version bump is nice, but it does not standardize a team. What standardizes a team is checking every workflow against the same repo conventions, every time, even when the product changes underneath you.
Put the durable facts in CLAUDE.md, nowhere else
The first thing that breaks on a team is memory. One engineer tells Claude Code about your service boundaries in a chat. Another never sees that chat. A third invents a third rule. Now you have three styles and a reviewer who has to reverse-engineer all of them.
The fix is a short CLAUDE.md with stable facts only: architecture boundaries, test commands, naming rules, and what a reviewer must verify. Keep task-specific detail out of it. If a line would change next week, it does not belong here.
The shape of Claude Code itself is a hint. Anthropic documents project setup, skills, hooks, permissions, and MCP as separate surfaces for a reason. Durable memory goes in CLAUDE.md. Reusable work goes in skills. Automated checks go in hooks. Access goes in permissions and MCP config. Mixing those is where the mess starts.
Make skills do real work, not store opinions
A good skill packages a repeatable capability: drafting release notes, running migration checks, doing a security pass, triaging a flaky test. It has a clear activation description and just enough procedure to stop you re-explaining the same thing.
Don't turn every preference into a long instruction file. When that happens your skills become a second wiki, and nobody reads a second wiki. If a skill is mostly opinions, it is probably a CLAUDE.md note in disguise.
Hooks have a similar failure. Hooks are genuinely handy for formatting, linting, test selection, or policy checks at predictable points. They turn scary when nobody knows why the agent stopped, changed, or retried something. The cure is disclosure: write down what each hook enforces, when it runs, and who owns it.
MCP is the last place trust leaks. The Model Context Protocol is a standard way for models and apps to connect to tools and data sources, but connection is not permission. Decide which servers are allowed, which actions are read-only, and which need a human to say yes before they run.
Paste this into CLAUDE.md and adapt it
Treat this as a starter, not a constitution. Drop the first block into CLAUDE.md, then move the review lines into your PR template.
## Claude Code team conventions
Repository context
- Prefer existing service boundaries over new abstractions.
- Before editing shared interfaces, inspect callers and tests.
- Do not add package managers, frameworks, or background services without asking.
Allowed workflow
- Start with a short plan for multi-file changes.
- Make the smallest coherent patch.
- Run the narrowest useful test first, then broaden when risk justifies it.
- Summarize changed files, tests run, and remaining uncertainty before review.
Hooks and checks
- Formatting and lint hooks may run automatically.
- Test hooks may suggest commands; long suites need human confirmation.
- A hook that blocks a change must print the rule it enforces and who owns it.
MCP and permissions
- Read-only docs and issue lookup are fine when the team configures them.
- Write actions in external systems require explicit human approval.
- Secrets, production data, and customer data are out of scope unless a named policy allows them.
Review checklist
- Does the patch follow the plan?
- Are the promised tests actually run?
- Is there a fast, safe way to undo this?
Review the receipt, not the whole chat
A pull request made with Claude Code is still a pull request. The reviewer should be able to see the plan, the changed files, the tests that ran, and the risky assumptions, and decide from that alone. If approving the change means replaying the entire session, the convention has not done its job.
A good way to read this through our methodology is the Plan step. Let the agent do first-pass decomposition and dependency mapping. You keep ownership of scope and priorities, and you review the sequencing. When that split feels fuzzy, the workflow usually is too.
Three habits keep reviews honest. Keep a short scope note naming the artifact, the owner, and the files the agent may touch. Require the reviewer to see the changed rule or verification output before approving. Put the fastest safe undo path right next to the change. None of these is heavy, and together they mean a new reviewer can defend a merge without spelunking through a transcript.
Start here
Pick the one artifact your reviewers already open, write it as a CLAUDE.md note, and take it into Team conventions to see if a new reviewer can defend a merge without replaying the chat.