Running Seven Claude Code Teams Alone

In October 2026 I had two side projects, each with its own instructions for Claude Code. On October 15 I merged them into one repository, claude-defaults, stripped out anything tied to one stack or one country, and gave every rule a stable ID. That was v1.0.0.

The idea at its heart is simple. One session that does everything ends up checking its own work. The session that writes a feature also decides it is secure, tested and ready, and it shares its own blind spots. So I split the work into teams, each one a separate Claude Code session with its own folder and its own branches:

• Design makes screens with fake data.
• Build builds features, end to end.
• Rehearsal shows the work behaves like production before users see it.
• Refactor changes structure without changing behavior.
• Red attacks a frozen candidate the way an outsider would, and never edits code.
• Ship owns the road to users.
• Upkeep keeps things healthy after launch.

And me. I make the decisions, and I am the only one who pushes. Two days later two more sessions joined: Content, for what users read, and Head, a front desk where I drop any idea and get back a plan by team.

Every change takes the same road. Team branches merge into alpha, where all the finished work meets. When a milestone is ready, Ship freezes one commit as a beta. Rehearsal tests it, Red attacks it, Ship fixes what they find, and then it is released to omega, which is what users have. Omega merges back into alpha, so the next round starts from what shipped.

The letters mean what they mean in software versions: alpha is early and unstable, beta is a frozen copy being tested, omega is the end of the road. There is no release schedule. Like Debian, a release happens when it's ready.

It looked tidy on paper. Then I started using it.

The first thing that broke was me. Seven sessions talk a lot, and every reply was written as if it were the only one I would read that day. Long paragraphs, steps buried in the middle, a question hidden in the fourth sentence. I would come back to a terminal and not know whether it was waiting for me, still working, or finished.

So the rules started to be about how a session talks to me.

The last line was there from the start. Every reply ends with exactly one of three lines: ✅ when everything I asked for is done, ⏳ when something is still running, 👉 when it needs one thing from me. With seven terminals open, that one line tells me where to look.

Then the steps. Anything I have to do is lettered a., b., c., one action each, so I can answer "a. DONE, b. DONE" and move on. A step I don't mention isn't done: it comes back in the next reply, marked "(still open)". A session never assumes I did something because I changed the subject.

Then the shape of a reply. It is now a report in sections, each under its own emoji heading, always in the same order: who asked for it, what was committed, my points, why, what it does, how it was tested, security, my steps, how to test it myself, prompts for other sessions, what is waiting. I can scan for 🛠️ and find every step in one place, because steps appear nowhere else.

The last rule of this kind is about a single phrase: "your usual way". I have no usual way; I have seven sessions. Now a step never comes without its exact command, and if the session doesn't know the command, it finds out before it asks me.

None of this makes the code better. All of it makes me faster, and I was the slowest part of the system.

Version 1.7, on October 17, added a rule I now consider the most useful one: no change that users can see counts as done until I have approved it on a preview. The session publishes a private page with screenshots at the sizes that matter (at least the smallest phone and a desktop, light and dark where there are both), before and after side by side, what changed, and its questions for me. One page per topic, updated in place. My OK on that page is the approval. Fake data only, always.

Later each preview also had to say which session made it, in its title and at the top of the page, because with seven sessions I was answering the right question in the wrong terminal.

It sounds slow. It is a two-minute look at a page instead of a week of "why does this look like that?"

Teams never assign work to each other. When Build finishes something Rehearsal needs to test, it writes a handoff: a file that is the next team's exact prompt.

In v1.0, I carried those files. Every handoff went from one terminal to another through me: copy, switch, paste, wait. In four days the teams wrote 94 handoffs, and I pasted most of them by hand. I had become a very expensive clipboard.

Version 2.0 fixed it with queues. The handoffs addressed to a team are its queue. When a team finishes a task, it picks the next ready handoff from its queue and starts when I type next, or straight away if I've said keep going. It stops and asks first only when it should: the handoff asks for something new I haven't approved, it is risky, it needs a push, a production step or my OK on a preview, or it is the third handoff bouncing between the same two teams on one topic. Before a team starts a handoff, I can still read it, change it, reorder it, hold it or cancel it.

A few other things changed in the same release. The project's instructions file has to stay small (about 40 KB); history and long reference move into their own documents, read only when needed. Security reviews are scheduled by risk, and each one covers everything released since the last. And there was security hardening of the git hooks. The hooks that keep private reports out of the repository had already got stricter, twice, in earlier releases.

The Refactor team had a name from day one, but not a method, and a cleanup without a method is how behavior changes quietly.

Version 2.0 gave it one, built from the books and papers I trust rather than from vibes. Martin Fowler's Refactoring for the catalog of named refactorings, and for expand and contract. Michael Feathers' Working Effectively with Legacy Code for characterization tests: pin today's behavior, oddities included, before you touch anything. Google's chapter on large-scale changes in Software Engineering at Google, for changes that span many files. The Mikado method for untangling. And published research on where defects come from: files that change often and are hard to read are where bugs live, so those go first.

The rules that came out of it are short. Find the hotspots with evidence, not taste. Build the safety net first. Structure and behavior never share a commit. Work in small slices, each mergeable on its own. Measure before and after. And performance tuning is not refactoring: it belongs to another team.