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

Tares gives you five levers over the crew: the repos your gh login can write to, the merge setting, the reviewer bar, the halt command and the optional releaser. Set them before you hand over a dependency upgrade project for your Go microservice. The crew runs as Claude Code sessions on your machine, and you decide how far it goes when you first run tares factory crew up.

How it works

The crew is an orchestrator, a reviewer, builders and, only if you ask for one, a releaser. Builders push and open pull requests with your gh login, so that login is the access you hand them. Each builder works on its own branch for one milestone and one repo of a project.

These are the levers you hold:

• Repos your gh login can write to. The crew needs gh signed in with write access to the repos it works in. Give that login write access to the Go service repo and nothing broader than you want the crew to use. On Tares Cloud you also pick the repos when you choose Connect GitHub. On a local Tares you add a GitHub token or App under Settings > GitHub.
• The merge setting. On the first crew up, Tares asks whether the crew merges on its own after review and green CI (the recommended choice) 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 have a second model check every commit, which needs the Codex CLI.
• Halting the crew. tares factory crew halt stops merges, pushes and new sessions until you run tares factory crew resume.
• Leaving the releaser off. The releaser tags and deploys, and it exists only if you ask for one. Without it, tickets end at merged on main.

You can also cap how many builders run at once and list anything you always allow. The answers are kept on Tares.

Set it up

1. Check which repos your gh login can write to, and sign in again with a narrower account if it reaches more than you want the crew to use.

   gh auth login

2. Install the CLI and start Tares locally. On Tares Cloud, run tares login instead.

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

3. In a second terminal on a local Tares, start the MCP endpoint every crew session shares.

   tares mcp --transport streamable-http

4. Give Tares access to GitHub, in Settings > GitHub for a local Tares or Connect GitHub on Tares Cloud. Pick only the Go service repo if you use Tares Cloud.

5. Bring up the crew and answer the settings questions.

   tares factory crew up

   For a cautious dependency upgrade run, choose to wait for your yes before merging, say no to the releaser, turn on the second-model check if you have the Codex CLI, and set a low number of builders.

6. Run the doctor. It reads go.mod and tells you whether Claude Code has a Go language server, which helps builders and the reviewer search the service. It also offers the install, and runs it only on a yes.

   tares factory doctor

7. Plan the upgrade work from the repo.

   tares factory spec "what you want to build"

   Describe the dependency upgrades you want, for example one milestone per group of modules. The plan becomes a Tares project with milestones, acceptance checks and tickets. Say yes when it asks whether to hand the project to the crew.

8. If something looks wrong while the crew works, halt it. Give a reason in place of the placeholder, and resume when you are ready.

   tares factory crew halt "<reason>"
   tares factory crew resume

The Get started page walks through the full setup in order.

What you get

• A crew whose GitHub reach is the access you gave your gh login, with Tares reading pull request, CI and merge state through the repos you connected.
• Pull requests for each upgrade that the reviewer holds to a fixed bar, with the verdict posted on the pull request.
• A merge policy you chose: merge on its own after review and green CI, or wait for your yes. You can set a single project to wait for your yes.
• A way to stop merges, pushes and new sessions at once with tares factory crew halt, and to carry on with tares factory crew resume.
• Tickets that end at merged on main when you leave the releaser off, so nothing is tagged or deployed by the crew.
• A record on Tares of the plan, the tickets, every review, the assumptions the crew made and your answers, so a crew that restarts carries on where it stopped.

When something else fits

• If you want to work one upgrade yourself in your own Claude Code session, use tares factory session for the project. The session’s record still lands on the project.
• If you want the crew to tag and deploy after a merge, ask for the releaser during crew up, and decide first whether you want that for a service in production.
• If the crew has to stop entirely, tares factory crew down stops every station, and Tares keeps the projects, tickets and answers.

Related