How do I limit what a Claude Code crew can touch while it does bug fixes 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 bar, halting the crew, and leaving the releaser off. You set most of them once, when you first run tares factory crew up. Together they decide where bug-fix changes go, who approves them, and how far a ticket travels after it merges.
How it works
The software factory for Claude Code is a crew of sessions on your machine: an orchestrator, a reviewer, builders and, only if you ask, a releaser. Each lever maps to one part of that crew.
- Your gh login. Builders push and open pull requests with your
ghlogin, which needs write access to the repos the crew works in. What that login can write to is what builders push with, so check it before you hand over a Python backend. - The merge setting. The first
crew upasks 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.
- Halting.
tares factory crew haltstops merges, pushes and new sessions until you runtares factory crew resume. You give it a reason in quotes. - The releaser. The releaser tags and deploys, and it exists only if you ask for one. Without it, tickets end at merged on main.
The first run also asks how many builders run at once and whether a second model checks every commit. Tares keeps your answers.
Set it up
-
Check which repos your
ghlogin can write to. Builders push and open pull requests with it, and the crew needs write access to the repos it works in. Sign in withgh auth loginif you have not. -
Bring up the crew and answer the settings questions.
tares factory crew up -
Pick the merge setting. Choose the option where the crew waits for your yes if you want to approve each bug-fix merge yourself. The recommended option merges on its own after review and green CI.
-
Answer no when it asks whether the crew releases. Without a releaser, a fixed bug stops at merged on main and nothing is tagged or deployed.
-
Lower the number of builders that run at once if you want fewer changes in flight. Say yes to the second-model check if you want every commit looked at twice. That check needs the optional Codex CLI.
-
Run the check that covers everything the crew needs.
tares factory doctor -
Plan the bug fixes with
tares factory spec, then hand the project to the crew when it asks. Questions reach you in the orchestrator’s session. Follow progress withtares factory crew status. -
Pull the brake whenever something looks wrong, and release it when you are ready.
tares factory crew halt tares factory crew resume
For the full walkthrough of bringing up the crew and planning a project, see Get started.
What you get
- Bug-fix pull requests that go through a reviewer holding every change to the same bar.
- A merge policy you choose: the crew merges after review and green CI, or waits for your yes. You can also require your yes for one project only.
- A stop button. After a halt, merges, pushes and new sessions wait until you resume.
- Work that ends 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 and the assumptions the crew made, so you can check its choices at the end of each milestone.
- A way to stop everything:
tares factory crew downstops every station, and Tares keeps the projects, tickets and answers.
When something else fits
- If you want to drive a small fix yourself, use
tares factory sessionto work on a project in your own Claude Code session instead of the crew. - If you want a person to approve every merge across all projects, choose the wait-for-your-yes merge setting when you first run
crew up, instead of relying on halts after the fact.
Related
- Build a software factory with Claude Code
- How do I limit what a Claude Code crew can touch while it does small features in a Node/TypeScript app?
- Where can I read back what the crew decided during bug fixes in a Python backend?
- Where can I read back what the crew decided during bug fixes in a Node/TypeScript app?
Still stuck? Get help