How do I limit what a Claude Code crew can touch while it does docs updates in a documentation website?

Tares gives you five levers over a Claude Code crew doing docs updates: your gh login’s write access, the merge setting, the reviewer bar, halting the crew, and leaving the releaser off. You set most of them once, when you run tares factory crew up, and you can halt the crew at any time. Together they decide what the crew can push, what merges and what ships from your documentation website.

How it works

The software factory for Claude Code is a crew of sessions running on your machine: an orchestrator, a reviewer and builders. Each lever below controls one part of what that crew can do.

• Your gh login. Builders push and open pull requests with your gh login, which needs write access to the repos the crew works in. Tares also reads the pull request, CI and merge state of every ticket with its own GitHub access, which you set separately.
• 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 it and CI is green. You can also have a second model check every commit, which needs the Codex CLI.
• Halting. tares factory crew halt stops merges, pushes and new sessions until you run crew resume.
• The releaser. The releaser, which tags and deploys, exists only if you ask for one. Without it, tickets end at merged on main, so a docs change never ships on its own.

Builders are one per milestone and repo, up to the number you allow. A smaller builder count means fewer pull requests open against your documentation website at once.

Set it up

1. Check that gh is signed in with write access to the documentation website repo. Give it only the access you want the crew to use, since builders push with this login.

   gh auth login

2. Install the CLI and start Tares. On a local Tares, also start the MCP endpoint in a second terminal. On Tares Cloud, run tares login instead.

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

3. Give Tares its own GitHub access. On Tares Cloud, choose Connect GitHub in your workspace settings and pick only the documentation repo. On a local Tares, add a token or App under Settings > GitHub.

4. Bring up the crew and answer the first-run questions with the tight settings: wait for your yes before merging, no releaser, and a low number of builders running at once.

   tares factory crew up

   The answers are kept on Tares.

5. Plan the docs updates as a project, in the repo that holds your documentation website.

   tares factory spec "what you want to build"

   The plan comes out as a spec, milestones with acceptance checks and tickets. You review it before you hand it to the crew.

6. Watch and intervene. Questions reach you in the orchestrator’s session, and the Crew page shows each project’s builders and the pull requests waiting for review.

   tares factory crew attach orchestrator
   tares factory crew status
   tares factory crew halt "checking the docs changes"
   tares factory crew resume
   tares factory crew down

   halt pauses merges, pushes and new sessions. down stops every station, and Tares keeps the projects, tickets and answers.

7. Run tares factory doctor after crew up to check everything the crew needs.

The full walkthrough is in Get started.

What you get

• Pull requests against your documentation website that a fixed-bar reviewer has checked, with the verdict posted on each one.
• Merges that happen only when you allow them: on their own after review and green CI, or after your yes.
• Docs changes that end at merged on main, because you left the releaser off.
• A stop button. tares factory crew halt pauses merges, pushes and new sessions, and crew resume carries on.
• A record on Tares of the plan, tickets, reviews, the assumptions the crew made and your answers. You can check every choice the crew made on its own at the end of each milestone, and a crew that restarts carries on where it stopped.

When something else fits

• If you want to drive each docs change yourself, use tares factory session to work on a project in your own Claude Code session instead of handing it to the crew. If the crew already has the project, saying yes to the takeover prompt stops the crew.
• If you want a project to merge only after you say yes every time, set that for the single project and let other projects merge on their own.

Related