Claude Code for Teams: Shared Conventions

TL;DR

• Claude Code for teams works best when your conventions live in a committed CLAUDE.md file.
• Shared settings stop each dev from making different choices about how the AI behaves.
• Skills are reusable instruction sets your whole team can pull from one place.
• Without shared conventions, every dev gets a different AI. That kills consistency.
• This guide shows you exactly how to set it up.

Solo Claude Code is one thing. Team Claude Code is a different problem.

When you use Claude Code for teams, each person brings their own habits, their own prompts, and their own expectations. Left alone, the AI behaves differently for everyone. One dev gets tight, focused responses. Another gets sprawling output that misses the point. A third adds emoji to everything.

That is not a Claude problem. That is a conventions problem. And conventions have a fix.

---

What goes wrong when teams skip this?

Nothing breaks immediately. That is the trap.

The cracks show up slowly. A junior dev asks Claude to write a component and gets one pattern. A senior asks for the same thing and gets a completely different one. Both are correct by Claude's standards. Neither is correct by yours.

Then someone asks Claude to follow your naming conventions and Claude does not know what they are. Someone else asks it to write in the company tone and gets generic AI copy.

You end up spending more time fixing AI output than the AI saves you. That is backwards. The answer is to treat your Claude configuration the same way you treat your codebase. Version control it. Commit it. Review it. Make it a team asset.

---

How does CLAUDE.md actually work?

CLAUDE.md is a plain markdown file. Claude reads it automatically at the start of every session in that directory. No extra setup. No prompts needed.

Think of it as a standing brief. Every time someone on your team opens Claude Code in your project, Claude already knows the rules.

A good team CLAUDE.md covers:

• What the project is. One or two sentences. Project name, tech stack, who it is for.
• What the code conventions are. Naming patterns, file structure, what goes where.
• What the voice is. If Claude writes copy or comments, what does it sound like?
• What Claude must never do. No modifying the auth module without review. No adding libraries without approval.
• What tools are in scope. Which MCP servers, which skills, which agents.

You commit this file to your repo. Every team member gets the same baseline. No arguments about "my Claude said X." Short is better. Claude reads the whole file every session. If it is 2,000 lines of edge cases, it wastes context and Claude starts ignoring the detail.

A CLAUDE.md is not documentation for humans. It is a brief for your AI. Write it like one.

For the full picture on what Claude Code can do, see the Claude Code complete guide.

---

What are committed settings and why do they matter?

Claude Code has a settings file. By default it lives at the user level. That means every dev has their own settings and they are almost certainly different.

You can commit a project-level settings file instead. It sits in your repo under the .claude folder and everyone on the team inherits it.

What goes in there? Things like which MCP servers are allowed, which commands Claude can run without asking, which directories Claude can write to, and the permission levels for tools.

Without committed settings, one dev has Claude running tests freely. Another has it blocked. One is on an older model. Another is on a preview. You cannot debug AI behaviour across your team if everyone is running a different configuration. Commit the settings. Make it a team decision, not an individual one. For the detail, see Claude Code settings and permissions.

---

What are skills and how do you share them?

Skills are reusable instruction files. Each one teaches Claude how to do a specific job in your project.

You might have a skill for writing blog posts in your brand voice, running a pre-deploy checklist, reviewing a pull request against your standards, or generating a client-facing summary from a technical spec.

Skills live in a .claude/skills/ folder. Each one is a SKILL.md file. Claude discovers them automatically.

The benefit for teams is obvious. You write the skill once. Every team member runs it. Everyone gets the same output. No one is reinventing the process each time they need it. Skills also encode institutional knowledge. If your best copywriter knows exactly how to write for your audience, put that in a skill. Now every dev can produce copy at that standard without being a copywriter.

If you want to go deeper on how Claude handles complex multi-step work, Claude Code subagents covers how skills connect to agent chains.

---

How do you get your team consistent?

Getting a team consistent with Claude Code is a rollout problem, not a technical one. The technical setup takes an hour. The human side takes longer. Here is what works.

Start with one person. Pick the person most likely to actually use it. Get them running with a CLAUDE.md and shared settings. Let them find the rough edges before you push it to everyone.

Write the CLAUDE.md together. Do not let one person write it in isolation and hand it down. Get the team in a room for an hour. Ask: what do we hate seeing in AI output? What decisions do we make constantly that Claude could just know? Write those down. That is your CLAUDE.md.

Review it like code. CLAUDE.md changes go through a pull request. Anyone can propose a change. The team reviews it. This stops one person from silently rewriting the rules.

Build skills for the things you repeat. Look at what your team asks Claude to do every week. If three or more people are doing the same thing, it probably needs a skill.

Set a shared model version in settings. Behaviour shifts between Claude versions. Lock the team to one version in your committed settings. Upgrade it as a deliberate team decision.

The teams that get the most out of Claude are the ones who treat AI configuration as a team responsibility, not an individual preference.

For how this connects to memory and longer-term context, see Claude Code memory. And if you want to see how it sits in a broader AI operating model, agentic AI for business is worth reading.

---

What about teams using Claude across multiple projects?

Some teams run Claude Code across five or ten repos. Each one has different needs. That is fine.

You can have a global CLAUDE.md at the user level for personal conventions. Then each project has its own CLAUDE.md for project-specific rules. Claude loads both. Project rules take priority over global ones.

For teams using The Orchestrators approach, this layered setup is standard. You get your team's shared conventions at the project level and each specialist agent gets its own focused context. The result is 3-5x team output without everyone stepping on each other.

---

FAQ

What if two people disagree on what goes in CLAUDE.md?
Treat it like any other team decision. Discuss it, vote if you need to, and document why you landed where you did. The CLAUDE.md is a living document. You can update it.

Does CLAUDE.md affect performance?
A short, focused CLAUDE.md has no real impact. A very long one eats into Claude's context window and can reduce quality. Keep it tight. If you need more, split it into skills.

Can we have different CLAUDE.md files for different environments?
Not directly. But you can use skills to load environment-specific context when needed. The CLAUDE.md stays shared and stable.

How do we handle new team members?
They clone the repo and get Claude Code running. The CLAUDE.md and committed settings are already there. Point them to the skills folder and run a 30-minute walkthrough. That is your onboarding for AI tooling sorted.

---

Ready to build a team that actually runs on AI?

Getting shared conventions in place is the first step. But most teams stop there and miss most of the value.

If you want a proper AI operating model for your business, one that turns your team's knowledge into repeatable AI output, book a call here and we will map out what that looks like for you.