How do I keep parallel Claude Code builders from colliding in a monorepo?

Tares keeps parallel Claude Code builders apart by starting one builder per milestone and repo, so a monorepo gets one builder per milestone. Each builder takes a ticket and works it on its own branch, then opens a pull request. The reviewer checks every pull request, and a change merges only after review passes and CI is green.

How it works

The software factory for Claude Code runs a crew of Claude Code sessions on your machine: an orchestrator, a reviewer and builders. The orchestrator starts the builders. For a project in a monorepo, which is one repo, that means one builder per milestone.

The collision controls come from how the work is divided:

• One builder per milestone and repo. Two builders never share the same milestone in the same repo.
• One ticket, one branch. A builder takes a ticket and works it on its own branch, so builders do not write into the same working branch.
• One pull request per change. Each builder opens a pull request for its ticket. The reviewer reviews every pull request to a fixed bar and posts its verdict on it.
• Merge only after review and CI. A builder merges its pull request once the reviewer passes it and CI is green.
• A cap on parallelism. You set how many builders run at once. The orchestrator starts builders up to that number.

Tares holds the plan, the tickets and their stages, and every review. If a session stops, the record stays on Tares and the crew carries on where it stopped. The watch that crew up starts brings back any station that stops.

A second model can also check every commit, if you turn it on in the crew settings.

Set it up

1. Check what you need. Claude Code signed in on a plan that allows background sessions, gh signed in with write access to the monorepo, plus git, jq and curl. The full list is on the software factory get started page.

2. Install the CLI and start Tares.

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up                  # console on http://127.0.0.1:8787

3. Start the MCP endpoint in a second terminal. Every crew session shares it.

   tares mcp --transport streamable-http     # http://127.0.0.1:8788/mcp

4. Give Tares access to GitHub. Builders push and open pull requests with your gh login. Tares reads the pull request, CI and merge state of every ticket itself, so add a GitHub token or App under Settings > GitHub on a local Tares, or choose Connect GitHub on Tares Cloud.

5. Bring up the crew and set the builder limit.

   tares factory crew up

   The first run asks how far the crew may go. Answer how many builders run at once, whether the crew merges on its own after review and green CI or waits for your yes, and whether a second model checks every commit. For a monorepo where you want to keep a close eye on parallel work, choose a lower builder count, or have the crew wait for your yes before merging.

6. Plan the project from the monorepo. Run this in the repo:

   tares factory spec "what you want to build"

   Claude Code interviews you, then writes the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md into a Tares project. Group related work into the same milestone, since one builder serves a milestone. Say yes when it asks whether to hand the project to the crew.

7. Follow the builders. The Crew page in the Tares console lists each open project with its builders and the pull requests waiting for review. Run tares factory projects to see each project’s progress, builders and repos, or tares factory doctor to check everything the crew needs.

What you get

• Parallel builders that each own a milestone and work a ticket on a separate branch.
• A reviewer that holds every pull request to the same bar, so no builder merges unreviewed work.
• Merges only when review passes and CI is green.
• A builder count you control, from one up to the number you allow.
• A record on Tares of the plan, tickets, reviews and the assumptions the crew made, so you check choices at the end of each milestone instead of watching terminals.
• One session to talk to. Questions from the crew reach you in the orchestrator, one at a time, each with a recommendation. A single project can also wait for your yes before every merge.

When something else fits

The crew is built for solo developers and very small teams who already work with Claude Code. It runs on one machine, on your own Claude Code login, against your own GitHub repos.

If the work is small, you may not need parallel builders. Run one project in your own Claude Code session instead:

tares factory session "<idea>"      # plan a small project and build it right there

The session is still bound to the Tares project, so your shared AGENTS.md and memory apply. If the crew already has the project, the session asks whether to take it over. Say yes and the crew stops, its builders push what they have, and the session carries on from their branches and pull requests.

Related