Learn Claude Code as a Team

By Rogier Muller06.28.26

The best way to learn Claude Code is to use it in a real repository with shared rules, small tasks, and human review. A good Claude Code workshop should teach the team workflow, not just the command line.

Claude Code team conventions are the durable repo rules, review expectations, permissions, and integration habits that make agent work predictable. Keep those conventions close to the product surface: CLAUDE.md for context, skills for repeatable workflows, hooks for guardrails, and MCP for integrations.

Start with the workflow, not the demo

Before you teach features, pick one boring workflow your team already understands. Good candidates are adding a unit test, fixing a small bug, updating a typed API client, or preparing a pull request summary.

This matters because Claude Code learns fastest from concrete boundaries. A task like “refactor auth” is too wide. A task like “add a failing test for expired invite links, then make it pass without changing the public route contract” gives the agent and reviewer the same target.

Don't treat the first session like magic. Do not start with a giant migration, a security-sensitive change, or a repo nobody on the team can explain. Start where a reviewer can spot drift in five minutes.

For a broader training path, keep this guide next to Team conventions. If you want a deeper companion on repo memory and review norms, see Team Conventions for Claude Agents.

Put durable rules in CLAUDE.md

CLAUDE.md supplies project instructions. Root guidance loads at session start; nested guidance is loaded when relevant files are read, as described in the memory documentation. Use it for rules that should survive across tasks: architecture boundaries, test commands, naming conventions, review expectations, and “never do this” constraints.

Keep it short enough that engineers will maintain it. A useful root CLAUDE.md is usually closer to a good onboarding note than a policy binder.

Watch for dumping task prompts into memory. “Fix the checkout bug” does not belong in CLAUDE.md. “Checkout code lives in apps/web/src/checkout; payment adapters must not import React” probably does.

Prerequisites for a first team rollout:

A repository with a working test command.
One owner who can approve changes to CLAUDE.md.
A small issue that touches real code but has low blast radius.
Agreement on what Claude Code may run locally.
A review checklist for agent-authored pull requests.

Step 1: name the boundary. Pick one repo area and one task type. For example: “frontend form validation fixes in apps/web,” not “all frontend work.”

Step 2: write the first CLAUDE.md. Add the commands, architecture notes, and review expectations Claude Code should follow every time. Keep local setup details out unless they affect agent behavior.

Step 3: add one repeatable skill. A Claude skill should package a workflow the team runs often, such as “write a regression test before fixing a bug” or “prepare a release-note draft.” Start with one skill before you build a library.

Step 4: set a hook boundary. Use hooks for checks that should run at predictable moments, such as formatting, linting, or blocking edits to generated files. Hooks are guardrails, not a replacement for code review.

Step 5: connect one MCP integration. Use the Model Context Protocol when Claude Code needs external context such as GitHub issues, design docs, or internal knowledge. Start read-only if the integration touches production systems or sensitive data.

Step 6: verify with a real pull request. Ask Claude Code to make the small change, run the agreed checks, and produce a PR summary. The setup works when a reviewer can see the task, files changed, commands run, and remaining risks without asking for a second explanation.

Use MCP and permissions like production plumbing

MCP is the integration layer that lets Claude Code connect to external tools and context sources through a standard protocol. In a team setting, that can mean GitHub issues, Slack threads, design files, docs, databases, or private knowledge bases.

The important habit is to separate context from authority. It is often safe for Claude Code to read an issue or architecture note. It is a different decision to let it write to a tracker, mutate a database, or trigger a deploy.

Watch for installing every integration on day one. Your first MCP server should answer a clear workflow question: “Can Claude see the issue acceptance criteria?” or “Can Claude find the service ownership doc?” If nobody can name the workflow, wait.

The note below describes team policy. It does not enforce access. Use runtime permissions and narrowly scoped service credentials for that boundary, and test a denied action before connecting real data.

For Claude Code teams, a short policy note makes that intent reviewable:


## Integrations and permissions

Claude may read GitHub issues and repository files needed for the current task.
Claude must ask before changing CI configuration, database migrations, auth code, billing code, or deployment settings.
Claude must not use production credentials, paste secrets into prompts, or modify generated files unless the task explicitly says so.

Check that a second engineer can repeat it

Carry forward two useful checks from the earlier rollout guides. First, write a skill description that names the task that should activate it; test one matching request and one unrelated request. Second, give each hook one purpose and record its event, expected failure behavior and owner.

Have another engineer run the pilot from a clean checkout with the same test command. Ask them to identify the loaded instructions, the skill used and the hook result without the original chat. If a connector is involved, test server-unavailable and permission-denied cases with synthetic data. Keep the failing evidence in the rollout note and fix the setup before widening access.

Turn review expectations into a habit

Agent-assisted work still needs review. The difference is that the review should check both the code and the path Claude Code took to get there.

Ask for receipts. A good PR summary should include the user-facing change, files touched, tests run, and known risks. This helps reviewers distinguish “done” from “plausible.”

Watch for reviewing agent output more casually because it arrived quickly. Fast code can still be wrong code. In hands-on AI coding workshops, this is usually the moment teams relax: the goal is not to distrust Claude Code, but to make the review loop visible enough that trust can grow.

Copy this team rollout plan

Paste this into your repo planning doc, then trim it to fit your team. The point is not to create ceremony. The point is to give Claude Code the same working agreement a new teammate would need.

# Claude Code team rollout plan

## Scope
- First repo area:
- First task type:
- Team owner:
- Reviewers:

## CLAUDE.md starter rules
- Architecture boundary:
- Test command:
- Lint/typecheck command:
- Files Claude should avoid editing:
- Changes Claude must ask about first:

## First skill to create
- Skill name:
- When to use it:
- Inputs Claude needs:
- Output Claude should produce:
- Example task:

## Hook boundary
- Check to run automatically:
- When it should run:
- What failure means:
- Who owns fixes to the hook:

## MCP integration
- System to connect:
- Read-only or write access:
- Data Claude may access:
- Data Claude must not access:
- Approval needed before writes:

## Review checklist for Claude-authored PRs
- The PR states the task and acceptance criteria.
- The summary lists files changed and why.
- Tests, lint, or typecheck results are included.
- Risky areas are called out plainly.
- Generated files, secrets, migrations, auth, billing, and deploy settings get extra review.
- A human reviewer can reproduce the result.

## Rollout verification
- One small PR was completed with Claude Code.
- The reviewer understood the change without a live walkthrough.
- CLAUDE.md was updated with anything the team learned.
- The next task is smaller, clearer, or better guarded than the first one.

Next step

Pick one low-risk issue this week and run the rollout plan against it. When the PR lands, update CLAUDE.md with the one rule you wish Claude Code had known at the start.

Editorial update

Updated 20 September 2026: consolidated the June 13 and June 14 rollout guides, removed the release-number pretext, and added repeatability checks.