Team Collaboration Patterns

Using Claude Code well on your own is one thing; getting a whole team to use it consistently well is another. Let's look at the patterns for adopting and running Claude Code effectively at the team level.

A shared team configuration system

Dividing responsibilities by file

project/
  CLAUDE.md               ← Shared team context (in git)
  .claude/
    settings.json         ← Shared team tool settings (in git)
    settings.local.json   ← Personal settings (.gitignore'd)
    skills/               ← Shared team Skills (in git, recommended)
      commit/
        SKILL.md
      review/
        SKILL.md
    agents/               ← Shared team subagents (in git)
    commands/             ← Legacy Skills (backward compatible)
      standup.md

skills/ vs commands/

.claude/skills/ is the recommended location. It lets you bundle supporting files (templates, scripts, etc.), and it takes precedence over .claude/commands/. Existing commands/ files keep working as-is.

.gitignore setup:

# Exclude only personal settings (keep team settings)
.claude/settings.local.json

Team CLAUDE.md template

# [Project Name] — Team Guide

## Project Context
- **Tech stack**: [list of stack]
- **Architecture**: [brief description]
- **Test framework**: [Jest/Pytest/etc.]

## Coding Conventions
- Function names: camelCase (TypeScript), snake_case (Python)
- Error handling: [describe approach]
- Logging: [describe approach]

## Prohibited
- Connecting directly to the production DB
- Including customer data in context
- Hardcoding API keys

## Running Tests
- Unit: `npm run test:unit`
- Integration: `npm run test:integration`
- Coverage: `npm run test:coverage`

## Deployment Process
[Summary of the team's deployment procedure]

## Common Skills
- `/commit` — Auto-write Conventional Commits
- `/review` — PR review
- `/standup` — Standup summary

Onboarding workflow

/team-onboarding — auto-generation command (v2.1.101+)

Once a team has settled on consistent Claude Code usage patterns, writing out "what to install first and what to learn first" for every new member becomes a burden. The /team-onboarding command automates this.

What the command does:

1. Scans the last 30 days of local Claude Code history
2. Aggregates slash command usage frequency, MCP server call counts, and work types per session
3. Generates the results as an ONBOARDING.md file — when a teammate pastes this file into Claude Code, an interactive onboarding guide starts, driven by the HTML instructions the command left behind

Structure of the generated file:

# Welcome to [Team Name]

## How We Use Claude
- Work Type Breakdown  (share by work type, ASCII bar chart)
- Top Skills & Commands (most-used commands)
- Top MCP Servers (most-called MCP servers)

## Your Setup Checklist
- Codebases (repositories you need access to)
- MCP Servers to Activate (MCP servers to enable + access permissions)
- Skills to Know About (custom skills the team uses often)

## Team Tips        ← TODO, fill in yourself
## Get Started      ← TODO, fill in yourself

Three points to polish right after generation:

• Team name: an auto-guessed value is inserted, so replace it with your real team name
• Team Tips: implicit tips not yet written in CLAUDE.md (e.g., "always start a session with /check")
• Get Started: one or two first hands-on tasks — fixing a typo, a simple question prompt, etc.

Relationship to the manual checklist: the auto-generated file is "a snapshot of what the team actually uses right now," while the manual checklist below is "the minimum rules the team must follow." The two are not mutually exclusive but complementary — a good approach is to run the auto-generation first, then pull organizational rules (security policy, code review procedures, etc.) from the manual checklist and merge them in.

Useful for the author too

/team-onboarding is meant for team sharing, but even solo users can use it as a self-review tool that shows at a glance "how I used Claude Code over the last 30 days." It reveals which commands you overuse and which MCPs you never touch.

New teammate onboarding checklist

## Claude Code Onboarding

### Step 1: Install and set up (30 min)
- [ ] Install Claude Code: `npm install -g @anthropic-ai/claude-code`
- [ ] Issue and configure an API key
- [ ] Read `CLAUDE.md` (understand the project context)

### Step 2: Basic practice (1 hour)
- [ ] Explore the codebase: "Explain the overall structure of this project"
- [ ] Bug-fix practice: solve one simple issue with Claude
- [ ] Experience a PR review with the `/review` Skill

### Step 3: Learn the team patterns (first week)
- [ ] Pair programming session (with an experienced member)
- [ ] Use the `/commit` Skill on your first PR
- [ ] Review the team's Claude Code usage guidelines

First-question templates for onboarding

Questions that help a new teammate understand the codebase:

> Explain the overall architecture of this project.
  Tell me the role of the core directories and how they connect to each other.

> When adding a new API endpoint, which files do I typically need to modify?
  Find one existing example and show me the pattern.

> Explain how testing works in this project.
  Show me an example of where and how to write tests.

Standardizing team workflows

Integrating the PR process

1. Start work
   git checkout -b feat/123-new-feature
   claude "Start implementing the feature based on issue #123"

2. During development
   claude "Write tests for what I just implemented"
   claude "Review this code (check against team conventions)"

3. Prepare the PR
   /commit  ← Auto-generate the commit message with a Skill
   /review  ← Self-review with a Skill, then open the PR

4. Respond to review
   claude "The reviewer flagged [comment]. How should I fix it?"

Regular team sessions

Weekly Claude Code usage sharing:

• Share the most effective prompts of the week
• Analyze failure cases (why they didn't work)
• Propose and add new Skills

Regularly updating the team CLAUDE.md:

# Once a month, review and update CLAUDE.md
git checkout -b chore/update-claude-md
# Update after team discussion
git commit -m "chore: monthly CLAUDE.md update"

Usage patterns by role

Junior developer

# Use it in a way that maximizes learning
> Explain why this code works the way it does.
  Give me only hints so I can fix it myself.

> Find the problems in this code I wrote.
  Explain how I should fix it, but don't fix it yourself.

Senior developer

# Focus on review and design
> Analyze the pros and cons of this architecture design.
  What problems would arise if we scaled 10x?

> Point out the code review focus areas.
  Especially from a security and performance perspective.

Tech lead

# Focus on raising the whole team's productivity
> Analyze this sprint's work and find the repetitive tasks
  we could automate with Claude Code.

> Write an onboarding document that helps a new teammate
  understand this codebase.

Managed Settings

On the Teams/Enterprise plans, managed settings let you enforce organization-wide policy. They are deployed via a server or MDM and cannot be overridden by lower-level settings:

// Example managed settings (deployed by an IT admin)
{
  "permissions": {
    "deny": ["Bash(curl *)", "Read(./.env)"]
  },
  "allowManagedPermissionRulesOnly": true,  // Ignore user/project rules
  "allowManagedMcpServersOnly": true        // Allow only approved MCP servers
}

Settings precedence: Managed > CLI flags > Local > Project > User

Managed deployment methods

• Server-managed: real-time deployment from the Claude.ai admin console (recommended)
• OS policy: macOS MDM, Windows Group Policy/Registry
• File-based: /etc/claude-code/managed-settings.json (Linux/WSL)

Sharing session results — Artifacts (GA on all plans)

Artifacts publishes the results of a Claude Code session as a shareable, live, interactive web page. Results that are hard to read as terminal text — an annotated PR diff, a data dashboard, side-by-side design proposals, a research timeline that fills in as it progresses — get hosted at a private claude.ai URL that you can share with teammates by link.

> Make an artifact that explains this PR with inline annotations on the diff

When you publish, Claude writes an HTML/Markdown file into the project and publishes it to a private URL (one approval before publishing). Republishing to the same URL stacks versions, and you share via Share in the page header (Team/Enterprise: specific people or everyone in the org; Pro/Max: a public link). Ctrl+] reopens the most recent artifact.

Requirements (all must be met)

Artifacts is GA (generally available) and requires all of the following to work. If any one is not met, only a local HTML file is written and nothing is published.

Requirement	Condition
Plan	Pro/Max/Team/Enterprise (Pro/Max are personal with no admin setup, Team is on by default, Enterprise requires the Owner to enable it)
Auth	Sign in to claude.ai via /login — API key, gateway token, and cloud credential sessions are not supported
Provider	Anthropic API only — Bedrock/Vertex/Foundry are not supported
Org policy	CMEK, HIPAA, and Zero Data Retention not applied
Environment	Claude Code CLI v2.1.183+ or Claude desktop app v1.13576.0+

It first launched as a Team/Enterprise beta, but it has now gone GA and includes the personal Pro/Max plans as well. To turn it off, set "disableArtifact": true in settings.

The page is a single self-contained HTML file with no backend (a CSP that blocks external requests, max 16MiB), so it is a capture of your work results, not an "app." Sharing outside the organization is possible via a public link — for Pro/Max the public link is the only sharing method, while for Team/Enterprise it is off by default, so the Owner must turn on External sharing in the admin settings.

Cost management (team level)

Ways to manage team API costs:

1. Use an organization account
   - Manage the whole team's usage under one account
   - Allocate budgets by department

2. Monitor usage
   - Check team usage in the Anthropic Console
   - Set monthly budget limits

3. Guidelines for high-cost work
   - Full analysis of a large codebase → get approval in advance
   - Automated batch jobs → run only after estimating the cost