Claude Code Rollout Drill

Use a Claude Code release as a small team drill, not a trivia exercise. The goal is to prove your conventions still work after the changelog moves: permissions, hooks, commands, skills, and review habits.

Claude Code training is the practice of teaching a team how to use Claude Code, Anthropic's coding agent, safely and consistently inside real repositories. For a claude code workshop, the best first session is one repo, one integration path, one review receipt, and one rollback plan.

Read the changelog like a release gate

Start with the official changelog entry, then write down only what the team can verify. As of June 29, 2026, Claude Code 2.1.196 is a versioned release in the official changelog; that is enough to trigger a short rollout check, but not enough to invent behavior that the changelog does not state.

The learning outcomes should be boring and testable:

• Engineers can find the changelog and summarize the release in one paragraph.
• Engineers can explain which MCP servers Claude may touch in the repo.
• Engineers can run the team slash command for a safe task.
• Reviewers can check the agent's evidence without replaying the whole chat.

This matters because Claude Code conventions decay quietly. A permission that was safe for one repo may be too broad for another, and a hook that helped one workflow may block a release branch.

The trap is treating training as a product tour. A tour creates confidence without muscle memory. A release gate creates a repeatable habit the team can use again next week.

For more team patterns in this cluster, keep the broader Claude Code team conventions page nearby, but keep this drill narrow.

Practice the same path every time

Run the session with 5 to 10 engineers and one lead reviewer. Keep it to 75 minutes for an experienced team or 90 minutes if the repo has multiple MCP integrations.

Use this flow:

• Five minutes: read the changelog entry and decide what needs verification.
• Ten minutes: inspect the repo's Claude Code conventions and allowed integrations.
• Twenty minutes: run one safe change through Claude Code.
• Twenty minutes: review the output, commands, hook behavior, and evidence.
• Ten minutes: record the convention update or decide no change is needed.

A good example is a service repo with GitHub issues, a read-only docs store, and a staging database MCP server. The team asks Claude to update a small validation rule, link the issue, and produce a review note. Nobody starts with a migration, secrets handling, or production data path.

The trap is letting everyone bring a different workflow. That feels inclusive, but it makes the session impossible to evaluate. Pick one path and repeat it until the team can see the seams.

Keep integrations boring and visible

Make the first MCP server read-only unless the training task truly needs writes. MCP is the integration layer that lets Claude Code connect to external systems such as GitHub, Slack, document stores, databases, design tools, or private knowledge bases.

For the drill, write a permission note in plain English before anyone runs the task. Example: Claude may read GitHub issue 428, read package documentation, and inspect schema metadata; Claude may not write to Jira, push branches, update Slack, or run database mutations.

This matters because MCP permissions are where team trust is won or lost. Engineers can tolerate a failed patch. They will not tolerate an agent that quietly writes to the wrong system.

The trap is asking, can Claude do this? The better question is, should Claude do this during training? Start with read, inspect, and propose. Add writes only when the review path is already strong.

Make commands and hooks do the repeatable work

Use a slash command for the workshop path so everyone practices the same motion. For example, /safe-fix issue-428 can ask Claude to read the linked issue, inspect the failing test, propose the smallest patch, run the relevant command, and produce a review receipt.

Use hooks only at clear boundaries. A pre-tool hook might block writes outside src/ and tests/; a post-tool hook might collect command output and changed files. Do not turn hooks into a second policy language that nobody can debug.

Claude skills are useful when the task needs reusable know-how, such as your release-note format, migration checklist, or security review recipe. Keep repository memory concise. A short CLAUDE.md note can point to durable repo rules, but the rollout plan should live in the training artifact, not in permanent memory by default.

The trap is encoding every preference as automation. If a reviewer cannot explain why a hook fired or why a skill activated, the team will work around it.

Check the after-state without replaying chat

End the drill with evidence a reviewer can scan in two minutes. The after-state is measurable when the team has a changelog note, a permission decision, the exact command path used, the files changed, tests run, and one explicit follow-up.

A useful reviewer question is simple: could another engineer approve or reject this agent-assisted change without reading the full transcript? If not, the workflow needs a better receipt.

For a related boundary pattern when teams use multiple agents, see Bound Claude Code Agent Teams. Keep that separate from this rollout drill unless your team already runs parallel agent work.

The trap is grading the session by whether Claude produced a good patch. The patch matters, of course. But training is successful when the team can repeat the process, spot unsafe permissions, and review the evidence.

Copyable team rollout plan

# Claude Code release rollout drill

Release under review: Claude Code 2.1.196
Date of drill:
Repo:
Facilitator:
Reviewer:
Participants:

## Goal
Verify that our Claude Code workflow still matches team conventions after the release.
We are testing the workflow, not trying to ship a large feature.

## Learning outcomes
- Everyone can summarize the changelog entry in one paragraph.
- Everyone can name the MCP systems Claude may read or write during this task.
- Everyone can run the approved slash command path.
- Reviewers can approve or reject the output from the receipt alone.

## Training task
Use one small issue or failing test:
- Issue or ticket:
- Expected files touched:
- Commands allowed:
- Commands blocked:

## MCP permission note
| System | Access during drill | Reason | Owner approval |
| --- | --- | --- | --- |
| GitHub issues | Read only | Understand task context | |
| GitHub pull requests | No write access | Reviewer opens PR manually | |
| Docs store | Read only | Check internal API guidance | |
| Staging database | No access | Not needed for this task | |
| Slack or chat | No access | Avoid noisy side effects | |

## Hook boundary
- Block writes outside approved paths:
- Capture command output for review:
- Stop on secret-looking changes or generated credentials:
- Do not add hooks during the drill unless the facilitator approves:

## Slash-command path
Command to practice:

`/safe-fix <issue-id>`

Expected behavior:
1. Restate task and allowed systems.
2. Inspect only relevant files.
3. Propose smallest change.
4. Run approved test or lint command.
5. Produce review receipt.

## Review receipt
Claude must report:
- Changelog checked:
- MCP systems used:
- Files changed:
- Commands run:
- Tests passed or failed:
- Risks or unknowns:
- Human follow-up needed:

## Rollback plan
If the workflow behaves unexpectedly:
- Stop the session.
- Revoke or narrow the relevant permission.
- Revert unreviewed file changes.
- Record the failed assumption.
- Schedule a smaller follow-up drill.

## Done when
- The reviewer can evaluate the change without replaying chat.
- The team agrees on one convention to keep, change, or delete.
- No permanent CLAUDE.md update is made unless the rule is durable across future tasks.

Common questions

• How should we run Claude Code training for a team?

  Run Claude Code training as a hands-on repo drill, not a lecture. Use one changelog entry, one small issue, one approved slash command, and one review receipt; 5 to 10 engineers in 75 to 90 minutes is a good starting size for teams that already use Claude Code.

• Is a Claude Code workshop enough for production use?

  A single Claude Code workshop is enough to start a shared habit, not enough to prove production readiness. Treat the first session as a baseline, then repeat the same rollout drill after meaningful changelog updates, new MCP servers, or new write permissions.

• Should we update CLAUDE.md during the rollout drill?

  Only update CLAUDE.md when the team discovers a durable repo rule. Do not store temporary training instructions, one-off issue context, or release-specific notes there; those belong in the rollout receipt so repository memory stays short and trustworthy.

• How strict should MCP permissions be for training?

  MCP permissions should be stricter in training than in normal expert use. Start read-only for external systems, block writes to chat and ticketing tools, and require an owner approval column before any server gets write access during a team exercise.

• What should a lead measure after the session?

  Measure whether the team can repeat the workflow without the facilitator. A good after-state has four artifacts: the changelog summary, the permission note, the command path, and the review receipt with files changed, commands run, risks, and follow-up.

Best ways to use this research

• Best for: Engineering leads who need a practical Claude Code for teams rollout habit tied to changelog updates, not a broad onboarding curriculum.
• Best first artifact: Paste the rollout plan into your repo planning doc and fill in the MCP permission note before the session starts.
• Best comparison angle: Compare read-only MCP training against write-enabled MCP training by review quality, not by how fast the agent finishes.
• Best follow-up: Turn one repeated manual review step into a slash command or hook only after two drills show the same need.

Further reading

• Claude Code — getting started
• Claude Code — skills
• Claude Code — hooks
• Claude Code — permissions
• Model Context Protocol — specification

Run the next drill

Pick one small issue and run this plan against your current Claude Code setup this week. If the receipt is hard to review, fix the workflow before adding more permissions.

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.