Where does a builder put its changes when the project changes a Go microservice?

Tares has a builder push its changes to its own branch in the Go microservice’s repo and open a pull request, never straight to the default branch. The reviewer reviews that pull request, and the builder merges it once the reviewer passes it and CI is green. Until then the default branch stays as it was.

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 one builder per milestone and repo of a project. When the project changes a Go microservice, the builder for that milestone and repo does the work.

The builder follows the same path for every ticket:

• It takes a ticket.
• It works on its own branch.
• It pushes the branch and opens a pull request, using your gh login.
• The reviewer reviews the pull request to a fixed bar and posts its verdict on the pull request.
• The builder merges the pull request once the reviewer passes it and CI is green.

The change reaches the default branch only through a pull request the reviewer has passed. Without a releaser, a ticket ends at merged on main. A releaser exists only if you ask for one, and it tags and deploys.

Tares reads the pull request, CI and merge state of every ticket itself, so the record of where each change stands is kept on Tares. If a session restarts, the crew carries on from the branches and pull requests already open.

You can also hold merges back. A single project can wait for your yes before every merge, even when the rest of the crew merges on its own. tares factory crew halt stops merges, pushes and new sessions until tares factory crew resume.

Set it up

Follow these steps to have a crew change your Go microservice through pull requests. They match the Get started guide.

1. Check that Claude Code is signed in, that gh is signed in with write access to the microservice’s repo, and that git, jq and curl are installed. Builders push and open pull requests with your gh login.

   gh auth login

2. Install the CLI.

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

3. On a local Tares, start Tares with tares up. In a second terminal, start the MCP endpoint every crew session shares.

   tares up
   tares mcp --transport streamable-http

   On Tares Cloud, run tares login instead and pick your workspace in the browser. There is no MCP endpoint to start.

4. Give Tares access to GitHub, so it can read each pull request, its CI and its merge state. On a local Tares, add a token or App under Settings > GitHub. On Tares Cloud, choose Connect GitHub and pick the repo. See GitHub for both.

5. Bring up the crew. The first run asks whether the crew merges on its own after review and green CI or waits for your yes.

   tares factory crew up

6. In the microservice’s repo, plan the project. The plan becomes milestones and tickets, and the orchestrator hands them to builders.

   tares factory spec "what you want to build"

7. Follow the pull requests on the Crew page of the console, and answer the crew’s questions in the orchestrator’s session.

   tares factory crew attach orchestrator

Go repos get an extra check. tares factory doctor finds a Go repo by its go.mod and says whether Claude Code has a language server for it, which helps builders and the reviewer search by symbol. tares factory crew up offers to install a missing server and does so only when you say yes.

What you get

• Every change to the Go microservice arrives as a pull request from a builder’s own branch, so you can see it, review it and trace it to a ticket.
• Nothing lands on the default branch until the reviewer has passed the pull request and CI is green.
• Several builders can work at once, one per milestone and repo, without writing to the same branch.
• A record on Tares of each ticket’s pull request, CI and merge state, so a restarted crew carries on where it stopped.
• A switch for control: let the crew merge on its own, or require your yes before every merge for a project.

When something else fits

• If you want to work on the Go microservice yourself with Tares tracking the work, run tares factory session to use your own Claude Code session instead of a crew.
• If you want the change tagged and deployed after it merges, ask for a releaser when you set up the crew, because without one tickets end at merged on main.

Related