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

Tares keeps parallel Claude Code builders apart by starting one builder per milestone and repo, with each builder taking a ticket and working it on its own branch. Each builder opens its own pull request, and the reviewer checks every one before it merges on main. You plan the project once, and the crew works the tickets in parallel without sharing a working branch.

How it works

The software factory for Claude Code runs a crew of sessions in the background on your machine: an orchestrator, a reviewer and builders. The structure keeps parallel work separate:

• One builder per milestone and repo. The orchestrator starts the builders. Two builders never share the same milestone in the same repo, so your Go service repo gets one builder for each milestone that is being worked.
• One ticket, one branch. A builder takes a ticket, works on its own branch, and opens a pull request. Parallel builders push to separate branches, not to one shared one.
• A reviewer on every pull request. The reviewer holds each change to a fixed bar and posts its verdict on the pull request. A builder merges only once the reviewer passes it and CI is green.
• A record on Tares. Tares holds the plan, the tickets and their stages, every review, the assumptions the crew made and your answers. If a session restarts, the crew carries on from that record.

You set how many builders run at once when you first bring the crew up, so you decide how much parallelism your Go service gets. If your service is split across several repos, each repo gets its own builder for a milestone. The orchestrator is the only session you talk to, and questions from every project reach you there, one at a time.

Set it up

1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed.

   gh auth login

2. Install the CLI and start Tares locally.

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up

3. In a second terminal, start the MCP endpoint every crew session shares. On Tares Cloud, sign in with tares login instead and skip this step.

   tares mcp --transport streamable-http

4. Give Tares access to GitHub, in Settings > GitHub for a local Tares or Connect GitHub on Tares Cloud. Tares reads the pull request, CI and merge state of every ticket, so it needs its own access to your Go service repo.

5. Bring up the crew. On the first run you choose whether it merges on its own after review and green CI or waits for your yes, and how many builders run at once.

   tares factory crew up

6. In the repo of your Go microservice, plan the project. Claude Code interviews you, then writes milestones with acceptance checks and tickets with a working doc each into a Tares project.

   tares factory spec "what you want to build"

7. Say yes when it asks whether to hand the project to the crew. The orchestrator picks it up and starts the builders.

8. Check progress and answer questions.

   tares factory crew status
   tares factory projects
   tares factory crew attach orchestrator

The full walkthrough is in Get started. Run tares factory doctor at any point to check everything the crew needs.

What you get

• Builders that work on separate branches, one per milestone and repo, so parallel work on your Go service does not pile onto one branch.
• A pull request for every ticket, reviewed to a fixed bar before it merges.
• A plan with milestones, acceptance checks and a working doc per ticket, so each builder starts from written instructions.
• A cap on parallelism that you choose when you set up the crew.
• A record on Tares of tickets, stages, reviews and your answers, so a restarted crew picks up where it stopped.
• The Crew page in the console, which shows each project’s builders, the question waiting for you and the pull requests waiting for review.
• A decision log: every choice the crew made on its own is written down, so you can check it at the end of each milestone.

You can also make one project wait for your yes before every merge, even when the rest of the crew merges on its own. That is useful when you want to look at a change to the service yourself first.

When something else fits

If your Go microservice change is small, work on it in a single Claude Code session with tares factory session, which plans a small project and builds it there with no crew. If you want the tickets to live outside Tares, keep them in Linear or GitHub Issues. Sessions change them there and Tares only reads them.

Related