Claude Code training for your team, on your own codebase.
Live sessions for engineering teams and the leaders who set their rules, run on your repo instead of a demo app. Each session leaves a file behind, so your team goes from trying Claude Code to shipping with it daily.
The founder runs every session: a former Head of Software Engineering with 14 years building production software.
Acme Inc training planNotes in your repo
Claude for leaders
Claude Code team workshop
rules/agents.md
CLAUDE.md
.claude/skills/spec/SKILL.md
docs/decisions/
.claude/skills/review/SKILL.md
rules/parallel-work.md
acme-app
1
Claude for leaders
What changes when agents write code
Heads of engineering and product, and the leads who will own the rules.
In the room
Where agents help on your roadmap and where they add risk: what they may touch, who reviews what, and how you will know it worked.
You leave with
A first draft of the rules for what agents may touch, ready for your teams to argue with.
rules/agents.mdadded to your repo
2
Claude Code team workshop
One shared setup
Every engineer on the team, with your repo open.
In the room
Set up Claude Code once for the whole team: instructions, permissions and the commands everyone runs, checked into the repo instead of living on one laptop.
You leave with
A setup every engineer, and every agent, starts from.
CLAUDE.mdadded to your repo
3
Claude Code team workshop
Specs before code
Engineers and the product manager who writes the tickets.
In the room
Take a real ticket from your backlog and write the spec the agent works from: the goal, the checks that prove it, what is out of scope.
You leave with
A spec skill the team runs on the next ticket.
.claude/skills/spec/SKILL.mdadded to your repo
4
Claude Code team workshop
Context agents can read
Engineers, and whoever knows why the code looks the way it does.
In the room
Write down the decisions that live in people’s heads, so an agent stops guessing at your architecture.
You leave with
Decision records next to the code they explain.
docs/decisions/added to your repo
5
Claude Code team workshop
Review that keeps up
Engineers and the people who approve pull requests.
In the room
Agents open more pull requests than people can read. Set up the checks that clear the mechanical comments, so reviewers read for intent.
You leave with
A review skill and a definition of done that runs on every pull request.
.claude/skills/review/SKILL.mdadded to your repo
6
Claude Code team workshop
Agents that stay out of each other’s way
Engineers already running more than one agent.
In the room
Run several agents on one codebase without collisions: who works where, and what waits for a person.
You leave with
Rules for parallel work the whole team follows.
rules/parallel-work.mdadded to your repo
Why doesn't Claude Code training stick?
Most teams have had the tutorial. Engineers still ask Claude Code one question at a time and paste the answer. Three reasons come up on almost every call.
It was taught on someone else’s code. A demo app has no history, no odd module, no payments code nobody wants to touch. The first real ticket looks nothing like the exercise.
Every engineer set it up alone. One person’s instructions live on one laptop. The next engineer starts from nothing, and the agent behaves differently for each of them.
Nobody wrote down the rules. What may an agent change on its own? Who reviews it? Until a leader answers that, careful engineers stop short and the rest guess.
We run the sessions on your repo with your leaders and your team. Every session ends in a commit, so the setup and the rules live where the next engineer looks first.
What changes for your team after the sessions
Every engineer starts from the same setup.
Instructions, permissions and the shared commands live in the repo, so the agent behaves the same for each person.
Tickets become specs before the agent starts.
The team writes the goal, the checks that prove it and what is out of scope, with a spec skill it runs on the next ticket.
Reviewers read for intent.
A review skill and a definition of done clear the mechanical comments on every pull request.
Leaders answer what agents may touch.
The rules are written down once, with an owner, and the teams work from them.
Your team keeps every file.
Files in your repo that the next engineer, and the next agent, read first. Open any of them.
acme-appnew
.claude/
skills/
spec/
review/
checks/
docs/decisions/
rules/
CLAUDE.mdOne shared setup
# acme-app
Read rules/agents.md before you change anything.
## Commands
- make test runs the suite. Run it before every commit.
- make check runs lint and types.
## Where things live
- api/ is the public API. Changes here need a spec.
- billing/ handles live payments. A person reviews every change.
.claude/settings.jsonOne shared setup
{
"permissions": {
"allow": ["Bash(make test)", "Bash(make check)"],
"deny": ["Read(./.env)", "Bash(git push:*)"]
}
}
.claude/skills/spec/SKILL.mdSpecs before code
---
name: spec
description: Turn a ticket into a spec before any code.
---
1. State the goal in one sentence.
2. Write the checks that prove it, before the code.
3. List what is out of scope.
.claude/skills/review/SKILL.mdReview that keeps up
---
name: review
description: Review a pull request against checks/definition-of-done.md.
---
Run make check first.
Comment only on intent, risk and missing tests.
checks/definition-of-done.mdReview that keeps up
# Done means
- Tests pass and cover the new behaviour.
- The spec’s checks are ticked.
- A person read the diff.
docs/decisions/0001-payments.mdContext agents can read
# 1. Payments stay behind one service
Status: accepted
Only billing/ talks to the payment provider.
Other code calls billing/, never the provider.
rules/agents.mdClaude for leaders
# What agents may touch
- On their own: tests, docs, internal tools.
- With a reviewer: api/, migrations.
- Never: billing/, secrets, production config.
Owner: head of engineering
rules/parallel-work.mdAgents that stay out of each other’s way
# Parallel work
One agent per branch, one branch per ticket.
Agents never edit the same directory at once.
Anything touching migrations waits for a person.
Every session ends in a commit,
so the habit stays in your repo after we leave.
Leaders set the rules, then the team builds on them.
Leaders decide what agents may touch. Then the team builds the setup that follows those decisions. Pick any session in the training plan to see what it covers.
acme-app
1
Pick the repo.
We read it before the sessions, so the exercises use your code from the first minute.
“should we let agents do this?”
rules/agents.md
2
Run Claude for leaders.
For heads of engineering and product and the leads who will own the rules. It turns “should we let agents do this?” into a written answer your teams can work from.
rules/agents.md
shared setup
specs
context
review
parallel work
acme-app
3
Run the Claude Code team workshop.
For the whole team, on your repo. Each block takes one habit (shared setup, specs, context, review, parallel work) and ends with the file that keeps it in place. Every file the sessions write is committed to your repo.
“You work with the person who does the work. No handoff, no juniors, no account manager.”
Yes. The Claude Code team workshop runs on your own repo with the whole team in the room. Claude for leaders runs alongside it for the people who own the rules.
Who is this for?
Teams whose engineers already have Claude Code and each use it differently. You want the sessions run on your own code, and someone on your side will own the rules once the sessions end.
Who is this not for?
Teams who want a recorded course to watch later, or prompt tips more than a shared setup. It also needs someone with time to commit the files the sessions write.
Who runs the sessions?
The founder runs every session. No juniors, no handoff to a trainer you have not met.
Can the training be remote or onsite?
Both. Remote sessions run live on a call with everyone in your repo. Onsite sessions run in your office.
Do you need access to our code?
We work in the repo you pick, with the access you give. Before the sessions we read it so the exercises use your code, and every file the sessions write is committed to your repo.
Can we train leaders only, or several teams?
Yes. Leaders only runs Claude for leaders on its own, and the rules it drafts go to your teams. One team adds the Claude Code team workshop on that team’s repo. Several teams start with leaders, so the rules exist, then one workshop per team.
What is the difference between training and a rollout?
Training teaches the team and leaves the first files. A Claude Code rollout installs the shared setup across one or more teams and reports where it landed.
What comes after training?
Training gets the first files into the repo. A Claude Code rollout installs the shared setup across one team in 14 days, or a department or the whole engineering org in 60 or 90. The Software Factory Buildcamp is for the lead who will run it after us.
Do leaders need to be technical?
No. Claude for leaders is about decisions: what agents may touch, who reviews what, how you will know it worked. The rules it drafts are written in plain language.
What is settled before the first session
Fit check first. If we're not the right team, we'll say so on the call.
You get a written scope and a fixed quote before anything starts.
Every file the sessions write is committed to your repo and stays there.
Bring us the bottleneck.
A 30 minute call with the founder about where work is stuck.
Spec
Build
Review
Release
Where work is stuck
Spec, build, review or release: wherever changes wait longest.
What exists today
The AI tools your teams use and the rules around them, if any.
What the next quarter needs
The launch or deadline the work has to hit.
1
Call
We find where the work waits and whether we can help.
2
Fixed scope
You get a written scope and a fixed quote before anything starts.
3
Kickoff
Work starts with your product and engineering leads.
If we're not the right fit, we'll say so.
Pick a time
Open the calendar and choose any free slot. You get an invite with a video link.