A Claude Code Team Training Plan

Do not turn Claude Code training into a tour of buttons. For a team, I would teach one shared workflow, then add the conventions that make the workflow safe enough to repeat. A Claude Code workshop should leave the repo in a better state than it found it, with review evidence, permission boundaries, and a short rollout plan the lead can inspect.

This fits best as part of Team conventions, not as a private productivity lesson. One person getting faster is useful. A team agreeing how Claude Code may read, change, test, and explain code is what makes the practice durable.

Start with one workflow the team already owns

Pick a workflow that already has a clear finish line. Do not start with open-ended architecture work, a vague backlog cleanup, or a cross-repo migration.

A good first exercise is the normal GitHub pull request workflow: create a branch, ask Claude Code for a small refactor, run the project test command, inspect the diff, and write a PR note that names the files changed and the checks run. That gives the team one concrete loop: delegate, test, review, then decide.

Keep integrations narrow. If the session needs GitHub or another MCP server, start with the least permission that supports the exercise. For a deeper setup pass, I would separate the training from the MCP design work and use a plan like Plan a Claude Code MCP Configuration.

Set outcomes a lead can inspect

Good training has observable after-state. By the end, a lead should be able to look at the repo and see what changed in the team workflow, not just hear that people felt more confident.

The learning outcomes I normally want are short:

• Developers can ask Claude Code to make a bounded change and stop before expanding the task.
• Developers can explain which files Claude Code read or changed during the work.
• The team has agreed when MCP access is read-only, when write access is allowed, and who approves it.
• Review notes include commands run, tests skipped, and remaining uncertainty.
• Durable team rules are recorded in the right place, with CLAUDE.md used only for repo memory that should persist.

That last point matters. CLAUDE.md is useful context, but it should not become a dumping ground for every prompt that worked once.

Run the workshop in a tight order

A two-hour session is enough for one team workflow if the group is small and the repo is ready. Four hours is better when the team needs to add a permission note, a hook boundary, or a reusable skill outline.

Use this order:

1. Choose one repo task that can be reviewed in a diff.
2. Write the task boundary before opening Claude Code: allowed files, expected output, and stop condition.
3. Run the change with Claude Code and keep the scope visible.
4. Run the existing test or lint command, even if it fails for a known reason.
5. Review the diff as a team and ask what evidence would make the change mergeable.
6. Record one convention the team wants to keep.

I treat step five as the Review step in our methodology: the human still owns the merge decision, so the agent output has to come with evidence. The review habit is more important than the first clever prompt.

Size the room and constrain permissions

Keep the first Claude Code workshop to four to eight engineers if the goal is hands-on practice. Larger rooms turn into demos unless you add facilitators and split the repo exercises.

Use one shared exercise, then let pairs run it on adjacent issues. A backend pair might refactor a validation function and run unit tests. A frontend pair might update a component prop and run the local type check. Both pairs should produce the same kind of review note.

Do not teach write-capable MCP access on minute one. Start with read-only access where possible, then add write actions only after the team has named the approval rule. Hooks can help enforce local checks, but they do not replace human review.

Skills are also better as a second pass. Once the team has repeated a workflow twice, package the stable part as a Claude skill or a slash command. Packaging too early freezes guesses.

Paste this rollout plan into your repo

This is the artifact I would leave behind. Put it in a team docs folder or an engineering onboarding note, then edit it after the first two real pull requests.

# Claude Code team rollout plan

## Training scope
- Repo:
- First workflow:
- Facilitator:
- Session length:
- Participants:

## Practice task
- Change to attempt:
- Files or folders in scope:
- Stop condition:
- Test or lint command:

## Permission boundary
- MCP servers used:
- Read access allowed:
- Write access allowed:
- Approval needed before:

## Team conventions to keep
- Durable repo memory to add to CLAUDE.md:
- Hook or local check to add:
- Skill or slash command worth packaging later:
- Prompt pattern to discard:

## Review evidence required on each assisted PR
- Summary of change:
- Files changed:
- Commands run:
- Tests skipped and why:
- Known uncertainty:
- Human reviewer:

## Measurable after-state
- At least two developers completed the same workflow.
- At least one assisted PR includes review evidence.
- The permission boundary is written down.
- One repo convention was added, changed, or deliberately rejected.

The important line is the measurable after-state. If the team cannot point to a PR, a permission note, or a changed convention, the session was only a demo.

Common questions

Should every team use the same Claude Code conventions?

No. Keep the review evidence consistent across teams, but let repo-level conventions differ. A payments service and a marketing site should not have identical permission rules.

Should CLAUDE.md be part of the first session?

Yes, but only lightly. Add durable rules that apply across tasks, such as test commands or architectural boundaries, and keep task-specific instructions in the issue or prompt.

Further reading

• Claude Code docs
• Claude Code skills
• Claude Code hooks

Next step

Bring one real repository and one reviewable task to hands-on training, and turn this rollout plan into a working team exercise.