How do I limit what a Claude Code crew can touch while it does test coverage in a Go microservice?

Tares gives you five levers over a Claude Code crew: the repos your gh login can write to, the merge setting, the reviewer bar, halting the crew, and leaving the releaser off. Set them before the crew starts on test coverage in your Go microservice, and use halt at any point to stop merges, pushes and new sessions. Everything the crew does stays on the record in Tares, so you can check it afterwards.

How it works

The crew is a set of Claude Code sessions on your machine: an orchestrator, a reviewer, builders and, only if you ask, a releaser. Each lever below limits a different part of what they can do.

• Repos your gh login can write to. Builders push and open pull requests with your gh login, so the crew can only change repos that login can write to. Tares reads each ticket’s pull request, CI and merge state with its own GitHub access, and that access covers only the repos you pick.
• The merge setting. On the first tares factory crew up, you choose whether the crew merges on its own after review and green CI, or waits for your yes. A single project can also wait for your yes before every merge while the rest of the crew merges on its own.
• The reviewer bar. The reviewer reviews every pull request 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. You can also turn on a second model, through the Codex CLI, to check every commit.
• Halting the crew. tares factory crew halt stops merges, pushes and new sessions until you run crew resume.
• The releaser. It tags and deploys only if you ask for one. Leave it off and every ticket ends at merged on main, so nothing is tagged or deployed.

The levers work at the level of repos, merges, reviews and sessions. For a test coverage job, you can also set the concurrency: the first-run questions include how many builders run at once.

Set it up

1. Check what the crew will be able to reach. Sign in with gh using a login that has write access to the Go microservice repo and no more repos than the crew should touch. Claude Code must be signed in too, and git, jq and curl must be installed.
2. Install the CLI and start Tares locally, then start the MCP endpoint every crew session shares in a second terminal. On Tares Cloud, run tares login instead and skip the MCP step. The Get started page has both paths.
3. Give Tares access to GitHub: Settings > GitHub on a local Tares, or Connect GitHub on Tares Cloud. Pick only the repos the crew works in.
4. Bring up the crew and answer the first-run questions. Choose merge after review and green CI, or wait for your yes. Say no to the releaser, decide on the second model, and set the number of builders.
5. Plan the work in the Go repo. Describe the test coverage you want, and the interview turns it into milestones with acceptance checks and tickets, so the scope is written down before any builder starts.
6. Keep halt ready. Run it with a reason when you want everything to stop, and resume when you are ready.

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up                  # first terminal, console on http://127.0.0.1:8787
tares mcp --transport streamable-http     # second terminal
tares factory crew up
tares factory spec "add test coverage to the Go microservice"
tares factory crew halt "stop for review"
tares factory doctor

Run tares factory doctor after crew up to check everything the crew needs. For a Go repo it also reads go.mod and tells you whether Claude Code has a language server for Go. If one is missing, it prints go install golang.org/x/tools/gopls@latest, then claude plugin install gopls-lsp@claude-plugins-official. crew up offers the same install and runs it only when you say yes.

What you get

• A crew that can only push to repos your gh login can write to.
• Merges that follow your choice: automatic after review and green CI, or only after your yes, for the whole crew or for one project.
• Every pull request held to the reviewer’s fixed bar before it merges, with the verdict posted on the pull request.
• A stop control. crew halt freezes merges, pushes and new sessions, and crew resume carries on.
• No tagging or deploying, because the releaser is off and tickets end at merged on main.
• A record on Tares of the plan, tickets, reviews and the assumptions the crew made, so you can check its choices at the end of each milestone. If you stop the crew with tares factory crew down, Tares keeps the projects, tickets and answers.

When something else fits

• If you want to supervise every step, work on the project in your own Claude Code session with tares factory session, still bound to the project on Tares.
• If you want each merge to be your decision, choose the wait-for-your-yes merge setting, either for the whole crew or for one project.
• If you want the crew to ship the change as well, ask for the releaser when crew up asks.

Related