Learn Claude Code as a Team

The best way to learn Claude Code, Anthropic's coding agent, 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. The official Claude Code changelog entry for 2.1.195 on June 26, 2026 is a useful reminder to 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.

The trap is treating 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 the related training topic. 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 is the always-on project context Claude Code reads to understand how your repository works. 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.

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

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

For Claude Code teams, a simple permission note in CLAUDE.md can save real pain:

## 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.

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.”

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

Common questions

• How can I learn more about Claude Code?

  Start by using Claude Code on one small, reviewable task in a real repository, then read the official getting started, skills, hooks, and permissions docs. The fastest learning artifact is a short CLAUDE.md plus one review checklist, because it turns product knowledge into a workflow your team can repeat.

• Should we run a Claude Code workshop before adopting it?

  Yes, if more than a few engineers will use it on shared code. A useful Claude Code workshop should include one live repo task, one CLAUDE.md edit, one permission decision, and one reviewed pull request. Avoid workshops that only show prompts without review or repository conventions.

• What belongs in CLAUDE.md versus a prompt?

  Put durable team rules in CLAUDE.md and put task-specific instructions in the prompt. Architecture constraints, test commands, ownership notes, and review expectations belong in memory; “fix this bug from issue 482” belongs in the session. This keeps Claude Code memory useful instead of noisy.

• Do Claude skills replace CLAUDE.md?

  No, Claude skills and CLAUDE.md solve different problems. CLAUDE.md gives always-on repository context, while skills package reusable workflows that should activate when the task calls for them. A team might keep API boundaries in CLAUDE.md and use a skill for writing regression tests.

• How much MCP access should a Claude team allow at first?

  Start with the smallest useful access, usually read-only context for one system. For example, let Claude Code read GitHub issues before you allow it to update tickets or trigger workflows. Write access should come with explicit permission rules, auditability, and a human review path.

Further reading

• Claude Code — getting started
• Claude Code — skills
• Claude Code — hooks
• Claude Code — permissions
• Model Context Protocol — specification
• Anthropic — Claude Code product page
• GitHub — anthropics/skills

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.