Skip to Content
Tares

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

With Tares, you limit what a Claude Code crew can touch with five levers: the repos your gh login can write to, the merge setting, the reviewer bar, halting the crew and leaving the releaser off. You set most of them once, in tares factory crew up, and you can stop the crew at any time. These levers apply to every project you hand the crew, including a test coverage project in a Python backend.

How it works

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

  • Your gh login. Builders push branches and open pull requests with your gh login. They can only write to repos that login can write to. Tares also needs its own access to read the pull request, CI and merge state of each ticket. On Tares Cloud you choose the repos with Connect GitHub. On a local Tares you add a token or App under Settings > GitHub. See Get started for the full setup.
  • The merge setting. On the first 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 change and CI is green. You can also have a second model check every commit, if you have the Codex CLI.
  • Halting. tares factory crew halt stops merges, pushes and new sessions until you run tares factory crew resume. Give it a reason in quotes.
  • No releaser. The releaser, which tags and deploys, 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. Builders are one per milestone and repo of a project, so the number you allow bounds how much work is in flight.

Set it up

  1. Sign in to gh with an account whose write access covers only the repos the crew should work in. For a Python backend, that can be just the backend repo. Check that Claude Code is signed in, and that git, jq and curl are installed.

    gh auth login
  2. Give Tares access to GitHub for the same repos only. On Tares Cloud, choose Connect GitHub and pick the repos. On a local Tares, add a token or App under Settings > GitHub.

  3. Bring up the crew and answer the questions on the first run.

    tares factory crew up
    • Choose whether the crew merges on its own after review and green CI, or waits for your yes. Pick the wait while you are learning what the crew does to your tests.
    • Say no when it asks whether the crew releases, so no releaser runs.
    • Choose whether a second model checks every commit.
    • Set how many builders run at once.

    The answers are kept on Tares.

  4. Plan the coverage work as a project. The spec turns your idea into milestones with acceptance checks and tickets with a working doc each, so the scope is written down before any builder starts. Say in the idea what the coverage work should cover.

    tares factory spec "what you want to build"
  5. Run the doctor. For a Python repo it also checks whether Claude Code has a language server, which helps builders and the reviewer search the code, and it prints what to run if one is missing.

    tares factory doctor
  6. Answer the crew’s questions in the orchestrator, the only session you talk to, and follow progress on the Crew page.

    tares factory crew attach orchestrator
  7. If you want to stop the crew mid-run, halt it. Run tares factory crew resume when you are ready to continue. To stop every station, run tares factory crew down. Tares keeps the projects, tickets and answers.

    tares factory crew halt

What you get

  • A crew that can write only to the repos your gh login can write to.
  • Merges that follow your choice: automatic after review and green CI, or only after your yes.
  • A reviewer verdict on every pull request before anything merges.
  • Work that ends at merged on main, because no releaser tags or deploys.
  • A stop control. A halted crew pushes and merges nothing and starts no new sessions until you resume it.
  • A written record on Tares of the plan, tickets, reviews, the assumptions the crew made and your answers, so you check the crew’s choices at the end of each milestone.

When something else fits

  • If you want to watch each step, use tares factory session to work on the project in your own Claude Code session instead of handing it to the crew.
  • If you want a crew to also tag and deploy, ask for the releaser. For a coverage-only job, leave it off.

Still stuck? Get help

Last updated on