How do I limit what a Claude Code crew can touch while it does small features in a Python backend?

Tares gives you five levers over a Claude Code crew: the repos your gh login can write to, the merge setting, the reviewer, a halt, and leaving the releaser off. Builders push with your gh login, so they reach only repos that login can write to. You answer the merge, release and builder-count questions when you first run tares factory crew up, and you can stop the crew with tares factory crew halt.

How it works

The crew is an orchestrator, a reviewer and builders. Each lever limits a different part of what they do.

• Repos your gh login can write to. Builders push and open pull requests with your gh login. The crew can only write to repos that login has write access to. Tares needs its own GitHub access too, but it uses that to read the pull request, CI and merge state of each ticket.
• The merge setting. On the first run of 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 the pull request and CI is green. You can also have a second model check every commit, which the first run asks about.
• Halting the crew. tares factory crew halt takes a reason and stops merges, pushes and new sessions until you run tares factory crew resume. tares factory crew down stops every station, and Tares keeps the projects, tickets and answers.
• Leaving the releaser off. The releaser, which tags and deploys, exists only if you ask for one. Without it, tickets end at merged on main, so the crew never tags or deploys.

The first run also asks how many builders run at once and what you always allow. Both narrow what the crew does at the same time and without asking.

Set it up

1. Decide which repos the crew may touch. Sign in with gh using an account that has write access to those repos and no others. Check that Claude Code is signed in and that git, jq and curl are installed.

   gh auth login

2. Install the CLI and start Tares locally, then start the MCP endpoint in a second terminal. On Tares Cloud, run tares login instead and skip the MCP step.

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up
   tares mcp --transport streamable-http

3. Give Tares access to GitHub for the same repos: Settings > GitHub on a local Tares, or Connect GitHub on Tares Cloud. This is how Tares reads pull request, CI and merge state.

4. Bring up the crew and answer the first-run questions with the limits you want.

   tares factory crew up

   • Choose whether the crew merges after review and green CI, or waits for your yes.
   • Say no to the releaser, so tickets end at merged on main.
   • Choose whether a second model checks every commit.
   • Set a low number of builders at once, and keep the list of things you always allow short.

5. Plan a small feature from the repo it builds on. Each feature becomes a ticket with a working doc and acceptance checks, and the spec ends by asking whether to hand the project to the crew.

   tares factory spec "what you want to build"

6. Run tares factory doctor to check everything the crew needs. For a Python backend it also reads your manifests, such as pyproject.toml or requirements.txt, and says whether Claude Code has a language server for Python. If one is missing, it prints what to run, so builders and the reviewer search the code with less guessing.

7. If something looks wrong, stop the crew.

   tares factory crew halt

   Pass a reason when you run it. When you are ready, run tares factory crew resume.

The full walkthrough is in Get started.

What you get

• A crew that writes only to the repos your gh login can write to.
• Merges that either happen after the reviewer passes the pull request and CI is green, or wait for your yes. You can set a project to wait before every merge even when the rest of the crew merges on its own.
• A reviewer that holds every pull request to the same fixed bar, with its verdict posted on the pull request.
• Work that ends at merged on main when you leave the releaser off, with nothing tagged or deployed.
• A stop control. After a halt, merges, pushes and new sessions stop, and the plan, tickets and answers stay on Tares.
• A record of every review, the assumptions the crew made and your answers, so you can check what it did at the end of each milestone.

When something else fits

• If you want to watch a small change yourself, run tares factory session instead. It opens a Claude Code session of your own, bound to the project, and the work still lands on Tares.
• If you want a tighter perimeter than one gh account gives you, use a gh login that can write only to the repos you want the crew to work in.

Related