Claude Code Workshop: How Teams Learn to Ship With Claude Code

Claude Code is Anthropic's agentic coding tool. It runs in the terminal, in IDEs such as VS Code and JetBrains, in a desktop app and on the web, and it can read your repository, edit files, run commands and work through multi-step tasks. Because so much of its power sits in configuration (project memory, permissions, hooks, subagents), a good workshop is less about prompting and more about setting up a repository so the agent behaves well for everyone on the team.

Below is the exercise sequence we recommend, in the order teams should do it. Each step produces something you commit.

Exercise 1: Install, authenticate and set permissions

Start with the boring part, because it decides how safe every later session is. Participants install Claude Code, sign in with the team's approved account type, and then look at permission settings together.

• Decide which commands may run without asking (for example the test runner and linter) and which always require approval.
• Store shared settings in the project's .claude/settings.json and personal overrides in a local settings file that is not committed.
• Agree that secrets never go into prompts or committed configuration.

Committed result: a project settings file with a reviewed allow-list.

Exercise 2: Write the CLAUDE.md together

CLAUDE.md is the project memory Claude Code loads at the start of a session. The /init command can draft one from the codebase, which is a reasonable starting point. The workshop value is in editing it as a team:

1. Add the exact build, test and lint commands.
2. Describe the architecture in a few sentences: where business logic lives, what not to touch.
3. List conventions the agent will not guess, such as error-handling patterns or naming rules.
4. Keep it short. Long, generic instructions dilute the important ones.

Committed result: a CLAUDE.md the whole team has reviewed. For the differences to AGENTS.md, see AGENTS.md and CLAUDE.md explained.

Exercise 3: Plan-first feature work on a real ticket

Pairs pick a small, real ticket. They use plan mode so Claude Code proposes an approach before changing files, review the plan, correct it, and only then let it implement. Afterwards they run the tests, read the full diff and open a pull request.

The debrief question is always the same: where did the plan differ from what you would have done, and who was right? That conversation teaches more about when to trust the agent than any slide.

Committed result: one pull request per pair, plus CLAUDE.md additions for every mistake the agent made.

Exercise 4: Custom commands and subagents

Repeated workflows belong in reusable building blocks rather than in people's heads.

Committed result: one or two commands and subagents in the project's .claude/ directory.

Exercise 5: Hooks as guardrails

Hooks run your own scripts at defined points in Claude Code's lifecycle, for example before or after a tool is used. Unlike instructions in CLAUDE.md, which the model may occasionally ignore, hooks are deterministic. Typical workshop hooks:

• Run the formatter after every file edit.
• Block edits to generated files, lockfiles or migration history.
• Refuse shell commands that match dangerous patterns.

Committed result: a hooks configuration with at least one formatting hook and one blocking rule.

Exercise 6: Connect tools with MCP

Model Context Protocol (MCP) servers give Claude Code access to external systems such as issue trackers, documentation, databases or browsers. In the workshop, connect one read-mostly integration, for example the issue tracker, so the agent can pull ticket details itself. Discuss which servers are trusted and what data they expose, because every MCP server extends what the agent can do.

Exercise 7: Headless runs and CI

Claude Code can run non-interactively (the -p print mode), which makes it usable in scripts and CI pipelines. A good closing exercise is a narrow automation: summarizing a failing test run, drafting release notes from merged pull requests, or responding to a mention in a pull request through the GitHub integration. Keep permissions tight and outputs reviewable.

How to run the day

• Group size: up to about twelve participants per trainer works well for hands-on labs.
• Pairs over solo work: one drives, one reviews; swap after each exercise.
• Timebox: exercises 1 to 3 take roughly the morning; 4 to 7 fit into an afternoon if the repository builds quickly.
• Follow-up: schedule a short session a few weeks later to review what the team changed in CLAUDE.md and hooks after real use.
• Preparation: have participants install Claude Code and confirm their account access the day before, so the morning is not lost to sign-in problems.
• Debrief: end with a fifteen-minute round where each pair names one thing they will delegate next week and one thing they will not.

Feature details evolve quickly, so check the current Anthropic documentation before the session. neooutput runs Claude Code workshops for teams in this build-as-you-learn style, on participants' own code where possible. If your team is also evaluating alternatives, our Claude Code vs. Codex comparison and the Claude Code best practices article are good preparation.