How do I limit what a Claude Code crew can touch while it does framework migrations in a monorepo?

Tares gives you five levers to limit what a Claude Code crew can touch: the repos your gh login can write to, the merge setting, the reviewer bar, halting the crew and leaving the releaser off. Builders push and open pull requests with your gh login, so the crew reaches only what that login can write to. Every pull request is reviewed to a fixed bar before it merges, and you can stop merges and pushes with one command at any time.

How it works

The software factory for Claude Code is a crew of sessions running on your machine: an orchestrator, a reviewer and builders. A framework migration in a monorepo goes through the same crew as any other project, so the limits come from how you set the crew up. See Get started for the full setup. These are the levers:

• Repo access. Builders push and open pull requests with your gh login. The crew can write only to repos that login can write to, so sign in with an account that has write access to the monorepo and the repos the migration needs, and to nothing else. Tares reads pull request, CI and merge state with its own GitHub access. On Tares Cloud you pick the repos when you choose Connect GitHub. On a local Tares you add a token or App under Settings > GitHub. The access you control here is per repo, through your login.
• The merge setting. The first crew up asks 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 after the reviewer passes it and CI is green. You can also have a second model check every commit, and the Codex CLI is optional for that.
• Halting. tares factory crew halt stops merges, pushes and new sessions until tares factory crew resume.
• 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, which limits how many changes are in flight in the monorepo.

Set it up

1. Sign in to gh with an account that has write access only to the repos the crew should work in. Builders push with this login.

2. Check that Tares has access only to the repos you want. 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 first-run questions. Choose whether the crew merges on its own or waits for your yes, say no to releasing, decide whether a second model checks every commit, and set how many builders run at once. The answers are kept on Tares.

4. Plan the migration with tares factory spec, describing the framework migration you want. The plan becomes a Tares project with milestones and tickets, and the crew builds them into pull requests. Answer its questions with tares factory crew attach orchestrator.

5. Watch the crew and stop it when you need to. Add a reason in quotes to halt.

gh auth login
tares factory crew up
tares factory crew status
tares factory crew halt
tares factory crew resume

6. Run tares factory doctor after crew up and whenever a station misbehaves. It prints a line for each thing the crew needs and the command that fixes each problem.

What you get

• A crew that can write only to the repos your gh login can write to.
• Every pull request held to the reviewer’s fixed bar, with the verdict posted on the pull request, and merged only when CI is green.
• The choice between automatic merges after review and your yes before merges. You can set the yes for one project only.
• A single command that stops merges, pushes and new sessions, and another that lets the crew carry on. Tares keeps the plan, tickets and reviews on its side, so a halted crew picks up where it stopped.
• No tagging or deploying, because the releaser is off. Work ends at merged on main.
• A written record of the assumptions the crew made and the questions it asked you, so you can check each milestone of the migration when it ends.
• tares factory projects, which lists every project handed to the crew with its progress, builders and repos.

When something else fits

• If you want to be in the loop on every step of one migration, run tares factory session with the project instead of the crew. It works in your own Claude Code session, and if the crew has the project it asks whether to take it over.
• If you need to stop everything, tares factory crew down stops every station. Tares keeps the projects, tickets and answers.

Related