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. Claude Code is Anthropic's coding agent, 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.

The trap is turning 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.

Common questions

• Where do Anthropic teams actually keep their Claude Code conventions?

  In the repository, next to the code, not in a shared doc or someone's chat history. The durable facts live in a short CLAUDE.md, reusable procedures live in skills, automated checks live in hooks, and access rules live in permissions and MCP config. Keeping them as repo artifacts is what lets a second engineer trust the output.

• Which Claude Code artifact should a team standardize first?

  Standardize the smallest artifact reviewers already touch: a CLAUDE.md note, a hook checklist, or an MCP permission rule. The goal is not documentation volume. It is one shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code ever reaches review.

• How do we know the convention is working?

  It is working when a reviewer can approve or reject agent output from the artifact and the evidence alone. Watch whether pull requests name the rule they used, include the checks they promised, and stop requiring anyone to replay a long session just to understand what actually changed.

• Does upgrading Claude Code change any of this?

  No. As of June 16, 2026 the changelog records version 2.1.179, but a new release does not standardize a team on its own. Treat each upgrade as a moment to re-check your conventions against the new surfaces, then keep the same small contract: what the agent must know, may do, must ask first, and what a reviewer verifies.

Start here

Pick the one artifact your reviewers already open, write it as a CLAUDE.md note, and take it into the related training topic to see if a new reviewer can defend a merge without replaying the chat.

Further reading

• Claude Code docs: getting started
• Claude Code docs: skills
• Claude Code docs: hooks
• Claude Code docs: permissions
• MCP specification 2025-11-25
• Claude Code product page
• Anthropic skills on GitHub