Claude Code: Ready to Merge
Two days with Claude Code in a real repository, planning small, checking with tests and reading the diff, until it opens a pull request you'd actually approve.
What you'll achieve:
- A clear model of what Claude Code sees, and how what you put in its context changes what comes back
- The habit of cutting a feature into changes small enough to check and review
- A plugin your team can install, holding the skills, hooks and subagents you built for the work you repeat
- One GitHub issue taken through to a pull request that someone reviewed and approved
- A line you can defend between what Claude runs on its own and what a person still reads
Prerequisites:
- You ship production code, in any language
- You're at home with Git and a terminal
- A laptop with the IDE or editor you already use, Git and a GitHub account
- A Claude Pro plan or higher, or an Anthropic API key. Pro can hit its limits on a full day of building.
- The runtime for the shared repository. Setup steps arrive before the workshop.
Claude Code wrote the feature in four minutes. Then you spent the afternoon reading it, trying to work out whether it fits the rest of the codebase, whether the tests it added actually test anything, and whether you'd put your name on the merge.
That's the gap a lot of teams are sitting in right now. The typing got fast. Knowing whether the result is any good didn't.
What we do for two days
Everyone works in the same repository, a real one with tests and a database, so the problems are the ones you'd hit on a Monday. Day one is about how Claude Code thinks: what goes into its context, what that costs, and how you set a codebase up so it has a fair chance. Then we cut a feature into small slices and take each one through plan, build and check.
Day two moves from you to your team. Skills, hooks, subagents and MCP for the work you repeat every week, packaged as a plugin everyone installs. Then GitHub: issues, pull requests and Actions, with permissions set for the job. We finish with one issue that ends as a pull request someone reviewed.
What this isn't
Not a feature tour. Claude Code changes every few weeks, and a list of commands would be stale before your next sprint. What lasts is the habit of planning small, verifying with tests instead of trust, and reading the diff rather than the story Claude tells you about it.
Is this for you?
If you ship production code, in any language, and you're comfortable with Git and a terminal, yes. It works for people who have never opened Claude Code and for people who use it every day. The first group gets the most out of day one. The second gets the most out of day two.
Before you come
Sort out your Claude access at home. A Pro plan works, but a full day of building can run through its limits, so consider a higher plan or an API key. Setup steps for the shared repository arrive before the workshop.
Curriculum
Two days in one shared repository, with real tests and a real database. Day one is you and Claude Code. Day two is Claude Code and your team.
How Claude Code works
Before you can trust what it writes, you need a picture of what it sees. Most surprises come from context nobody chose on purpose.
Key Topics:
- What goes into its context, and what you should keep out
- Picking a model, and what each choice costs you
- Why the same prompt gives a different answer in a different session
Setting the codebase up for it
Claude Code does its best work in a codebase that tells it the rules. Most of that is work you'd want for a new colleague anyway.
Key Topics:
- Project instructions that say what matters here, and nothing else
- Tests it can run, so it finds out for itself when it's wrong
- A short spec before the first prompt
Plan, build, verify
A big prompt gets you a big diff that nobody wants to review. We cut the feature into slices and take each one through the same loop.
Key Topics:
- Slicing a feature into steps you can check one at a time
- Planning before any code gets written
- Tests and linters as the feedback Claude listens to
- Reading the diff, not the summary Claude writes about it
Shaping it to your team
The work you repeat every week shouldn't need a fresh prompt every week. We turn it into something the whole team shares.
Key Topics:
- Skills for the jobs you keep explaining
- Hooks that run checks without anyone asking
- Subagents for work that needs its own context
- MCP connections to the tools you already use
- Packaging all of it as a plugin the team installs
Claude Code on GitHub
The capstone. One GitHub issue goes all the way to a pull request that a person reviewed, with Claude doing the typing and you doing the judging.
Key Topics:
- Working from issues and pull requests
- Running Claude Code in GitHub Actions
- Permissions set for the job in front of it
- When to stay in the loop, and when to let it run
Catch it in public
When this runs in public it runs at a conference, and the conference sells the seat. Registration goes to them, not to me.
No public dates for Claude Code: Ready to Merge
Nothing on the public calendar for this 2-day intensive right now. Black Lab Studios books private sessions all year.
Frequently Asked Questions
Want this for your team?
Private sessions run on-site or remote, against the codebase your team actually works in. Black Lab Studios, the company I founded, handles the scoping and the contract. I run the room.