Can a crew of Claude Code sessions handle docs updates in a Go microservice?

Yes, Tares runs a crew of Claude Code sessions that can take docs updates in a Go microservice from plan to merged pull requests. The orchestrator starts one builder per milestone and repo, and each builder opens a pull request. A pull request merges only after the reviewer passes it and CI is green. You plan the work with tares factory spec and the crew builds the tickets.

How it works

The software factory for Claude Code is a crew that runs in the background on your machine. The roles are the same for any repo, so a Go microservice gets the same crew as any other project.

• Orchestrator: hands out work, answers the others and brings you what needs you. It is the only session you talk to.
• Builders: one per milestone and repo of a project, started by the orchestrator, up to the number of builders you allow. Each takes a ticket, works on its own branch and opens a pull request.
• Reviewer: reviews every pull request to a fixed bar and posts its verdict on the pull request.
• Releaser: only if you ask for one. Without it, tickets end at merged on main.

For a single Go microservice, you have one repo. Builders are therefore assigned per milestone: if you split your docs updates into two milestones, the orchestrator starts a builder for each. If the docs live in a second repo, that repo gets its own builder for the same milestone.

The pull request has to clear two things before it merges. The reviewer must pass it, and CI must be green. A builder merges it itself once both hold. Your plan also carries milestones with acceptance checks and an AGENTS.md, so each milestone has its own bar to meet.

For Go, Tares reads go.mod to detect the language. Builders and the reviewer search less when Claude Code can find definitions, references and callers through a language server. tares factory doctor says whether Claude Code has the Go server (gopls) and prints what to run if it is missing. tares factory crew up offers the same install and runs it only when you say yes.

Tares keeps the plan, the tickets and their stages, every review, the crew’s assumptions and your answers. If a session restarts, the crew carries on from that record.

Set it up

Follow these steps in order. Steps marked local apply to a local Tares, and the Tares Cloud step replaces the local ones.

1. Check that Claude Code is signed in on a plan that allows background sessions. Sign in to gh with write access to the repo, and make sure git, jq and curl are installed.

   gh auth login

2. Install the CLI.

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

3. Local only: start Tares, then start the MCP endpoint in a second terminal. The crew reaches Tares only through that endpoint.

   tares up
   tares mcp --transport streamable-http

4. Tares Cloud only: sign in and pick your workspace in the browser. There is no MCP endpoint to start.

   tares login

5. Give Tares access to GitHub, under Settings > GitHub for a local Tares or with Connect GitHub on Tares Cloud. Tares reads the pull request, CI and merge state of every ticket itself.

6. Bring up the crew. The first run asks how far the crew may go: whether it merges on its own after review and green CI or waits for your yes, whether it releases, how many builders run at once, and more.

   tares factory crew up

7. In the microservice repo, plan the docs work. Name the milestones you want, for example one for the API reference and one for the runbooks.

   tares factory spec "update the docs for the orders service"

8. Say yes when it asks whether to hand the project to the crew. Answer the orchestrator’s questions with tares factory crew attach orchestrator, and run tares factory doctor to check the Go language server and everything else the crew needs. The full walkthrough is in Get started.

What you get

• Docs changes land as pull requests on their own branches, one builder per milestone and repo, each merged once the reviewer passes it and CI is green.
• Every pull request is held to the same reviewer bar, with the verdict posted on the pull request.
• You talk to one session, the orchestrator. Questions reach you one at a time, each with a recommendation.
• The Crew page in the Tares console shows each project’s progress, its builders and the pull requests waiting for review.
• Choices the crew made on its own are written down, so you can check them at the end of each milestone.
• If the project has a Go repo, Claude Code can use gopls for symbol search once doctor shows it installed.

When something else fits

• For a small docs fix, work in your own Claude Code session instead with tares factory session "<idea>". It plans and builds right there, still on Tares.
• If you want a human to approve each merge, choose that setting when crew up asks, so the crew waits for your yes.

Related