Can a crew of Claude Code sessions handle bug fixes in a Go microservice?

Yes, Tares runs a crew of Claude Code sessions that turns bug-fix tickets for a Go microservice into pull requests merged on main. The orchestrator starts one builder per milestone and repo, and the reviewer and CI decide whether each pull request merges. The crew treats a Go repo like any other repo, so what changes is how you plan the milestones and which checks your CI runs.

How it works

You plan the bug fixes as a Tares project, and the crew builds the tickets into pull requests. The pieces that matter for a Go service are:

• Builders per milestone and repo. The orchestrator starts builders, one per milestone and repo of a project, up to the number of builders you allow. A single Go microservice is one repo, so the number of builders follows the number of milestones you plan. Each builder takes a ticket, works on its own branch and opens a pull request.
• The reviewer. One reviewer session reviews every pull request to a fixed bar and posts its verdict on the pull request.
• CI on your repo. A builder merges its pull request once the reviewer passes it and CI is green. Tares reads the pull request, CI and merge state of every ticket itself, so the checks that gate a merge are the ones your repo’s CI already reports.
• Acceptance checks. /tares:spec writes milestones with acceptance checks and tickets with a working doc each. It also writes an AGENTS.md for the project.
• The record on Tares. Tares holds the plan, tickets and their stages, every review, the assumptions the crew made and your answers. If a session restarts, the crew carries on where it stopped.

The crew runs on your machine as Claude Code sessions, on your own Claude Code login, against your own GitHub repos.

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 service’s repo, plus git, jq and curl.
2. Install the CLI, start Tares and start the MCP endpoint the crew sessions share. Then run tares login if you use Tares Cloud.
3. Give Tares access to the repo. On Tares Cloud, choose Connect GitHub in your workspace settings and pick the repo. On a local Tares, add a GitHub token or App under Settings > GitHub. Builders push and open pull requests with your gh login.
4. Make sure your Go service’s CI runs the build and test steps you want every pull request to pass. A merge waits for green CI, so those steps are the gate.
5. Bring up the crew with the one command to remember:

tares factory crew up

6. From the service’s repo, plan the bug fixes. Describe the bugs, ideally grouped into milestones so builders can work on separate groups:

tares factory spec "what you want to build"

7. Answer the interview, then say yes when it asks whether to hand the project to the crew. The orchestrator picks it up.
8. Follow progress with tares factory projects, which lists each project’s progress, builders and repos. Run tares factory doctor at any point to check everything the crew needs. You can also open the Crew page in the console.

If you want a human yes before each merge, you can set that for a single project. The crew’s other projects keep merging on their own.

What you get

• Bug-fix tickets built into pull requests on their own branches, each held to the reviewer’s fixed bar and to your CI before it merges on main.
• Builders assigned by milestone and repo, so a milestone’s work is handled by its own builder without you assigning anything.
• One session to talk to. Questions from every project reach you in the orchestrator, one at a time, each with a recommendation.
• A written record of every review, assumption and answer, so you can check the crew’s choices at the end of each milestone instead of during every step.
• Other projects that keep moving while one waits for your answer.

Start from the Get started page for the full walkthrough.

When something else fits

• If the fix is small, work on it in your own Claude Code session with tares factory session, still on Tares, instead of bringing up the whole crew.
• The software factory is built for solo developers and very small teams on one machine. If you need a shared setup for a larger team, it does not cover that today.

Related