Hands-On Claude Code Workshops for UK Development Teams

A good Claude Code workshop starts with team rules, not prompt tricks. Before your team learns clever phrasing, it needs to agree on what the agent may trust, what changes need review, and where those rules live. Claude Code, Anthropic's coding agent, gets safe to use the moment a repository tells it how this team works.

A team convention is a written rule, stored with the code, that tells both Claude Code and reviewers how this repository expects changes to be made. That is the thing worth building together, with a real repo open on the screen instead of a clean sample app.

The version number is a recency marker, not a workflow. The official changelog records Claude Code 2.1.176 on June 12, 2026, but no release note tells your team how to review generated code or maintain a CLAUDE.md. You write that part.

Set up a CLAUDE.md your team will actually follow

The hard part of adoption is not access to the agent. It is keeping ownership when the agent moves faster than the review habit around it. So the first job is a shared file the agent reads and a reviewer enforces.

Keep it short on purpose. A bloated CLAUDE.md, full of build notes, old incidents, and half-made decisions, gets ignored fast. Use a simple filter: if a rule should still apply next month and a reviewer would enforce it, it belongs in the file. If it only helps one task, keep it in the prompt.

Give the file an owner. A repository convention needs a maintainer the same way architecture-sensitive code does. The people who review risky changes should also review changes to the rules, so the agent never inherits stale guidance that no one is accountable for.

# CLAUDE.md

## Claude Code team convention: delivery-safe changes

Purpose: Keep Claude Code useful without weakening code ownership.

Applies to: All production code changes in this repository.

Context rules:
- Prefer this CLAUDE.md over personal memory when repository guidance conflicts.
- Treat architecture notes here as durable rules, not task instructions.
- Ask for clarification before changing public APIs, data models, auth logic, billing logic, or deployment configuration.

Working rules:
- Before editing, summarise the intended change in 3 bullets.
- Keep generated changes inside the requested scope.
- Add or update tests when behavior changes.
- Do not introduce a new dependency without naming why the existing stack is insufficient.

Review checklist:
- Does the diff match the stated scope?
- Are tests meaningful, not only snapshot or happy-path tests?
- Did Claude Code touch security, permissions, data deletion, or migrations?
- Are any generated comments hiding unclear logic?
- Is a human maintainer comfortable owning this code next month?

Hook and permission boundary:
- Formatting and lint hooks may run automatically.
- Destructive commands, production credentials, and external write actions require explicit human approval.

MCP boundary:
- External systems may be read only when the task names the system and purpose.
- External writes require a linked issue or pull request note.

Make the adoption path boring: one engineer proposes the CLAUDE.md change in a normal pull request, a maintainer reviews it, and the team links it from onboarding notes.

Write a review checklist before anyone generates code

Review theatre is the quiet killer. The diff compiles, someone gives it a glance, and it merges. A generated diff deserves more attention than a hand-written one, because the author cannot answer questions about intent in the hallway.

Decide what a reviewer must check before the work starts, not after. Name the AI-specific risks out loud: hidden behavior changes, missing tests, new dependencies, security boundaries, and edge cases that quietly disappeared. The agent can produce the diff, but the team owns the merge.

You can paste this checklist into a pull request template today:

- [ ] Name the Claude Code artifact first: a CLAUDE.md fragment, a skill outline, a hook boundary, an MCP permission note, or a review checklist.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect it without replaying the whole chat.

If a reviewer cannot approve or reject the change from the artifact and the evidence alone, the work is too big or the rule is missing. Both are fixable before the next run. For more patterns in this cluster, see the related training topic.

Set guardrails without hiding the rules

Hooks and permissions are useful, but they are guardrails, not judgement. A hook can block an unsafe command or enforce formatting. It should never become an invisible policy engine that nobody can explain during an incident.

Treat the Model Context Protocol the same way. MCP is an integration layer for connecting applications and data sources, and in a team setting that access should be explicit. Name the system, the allowed operation, and the review expectation before the agent uses it in delivery work.

Three small habits keep the agent honest. Keep a one-line scope note that names the artifact, the owner, and the files the agent may touch. Require the reviewer to see the changed rule or checklist before approving. Write the fastest safe undo path next to the change, so recovery never means reconstructing a session.

In our methodology, the Review step matters most here: review the operating rule before you review the agent's next large change. That feels slower once. It saves time every week after.

Common questions

• How should a team start with hands-on Claude Code workshops?

  Start by turning the workshop into one visible team rule, not a loose preference. For most teams that means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing. Leave the session with a single rule, a single review habit, and one change a maintainer is willing to own.

• Which Claude Code artifact should we standardize first?

  Standardize the smallest artifact your reviewers already touch: a CLAUDE.md note, a hook checklist, or an MCP permission rule. The goal is not documentation volume. It is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before any generated code reaches review.

• How do we know the convention is working?

  It works when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule they used, include the promised checks, and skip the long session replay. If a new reviewer can defend the merge without reading the chat, the convention is doing its job.

• What does Claude Code 2.1.176 change about this?

  The version matters far less than the rules around it. The June 12, 2026 release is a useful recency marker, but a changelog entry never tells your team how to maintain a CLAUDE.md or when a hook is too strict. Pin your conventions to review habits, not to whichever build you happen to run.

Where to go next

Take this into the related training topic and test one thing: can a new reviewer defend the merge without replaying the chat? If yes, your convention is working.

Further reading

• Claude Code docs: getting started
• Claude Code docs: skills
• Claude Code docs: hooks
• Claude Code docs: permissions
• MCP docs: specification 2025-11-25
• claude.com: Claude Code product
• github.com: anthropics skills