Where does a builder put its changes when the project changes a monorepo?

In Tares, a builder puts its changes on its own branch in the repo and opens a pull request, so nothing reaches the default branch until the reviewer has passed that pull request. A monorepo is one repo, so its builders push to that one repo and every change arrives as a pull request. The builder merges it only after the reviewer passes it and CI is green.

How it works

The software factory for Claude Code is a crew of Claude Code sessions: an orchestrator, a reviewer and builders. The orchestrator starts builders, one per milestone and repo of a project. For a monorepo project, the repo is the monorepo, so each milestone gets a builder working in that repo.

Each builder follows the same path for every ticket:

• It takes a ticket.
• It works on its own branch.
• It pushes the branch and opens a pull request, using your gh login.
• The reviewer reviews the pull request to a fixed bar and posts its verdict on it.
• Once the reviewer passes it and CI is green, the builder merges it.

Builders never write straight to the default branch. The only way a change gets there is a pull request the reviewer has passed. You can also make a single project wait for your yes before every merge, even when the rest of the crew merges on its own.

Tares keeps the record: the plan, the tickets and their stages, every review and your answers. Tares reads the pull request, CI and merge state of every ticket itself, so it needs its own access to the repo. If a session stops, the branch and pull request are still there and the crew carries on from them.

Set it up

Set up the crew once, then hand it the monorepo project. These steps are for a local Tares, and the order matters. For the full walkthrough, see Get started.

1. Check that Claude Code is signed in, that gh is signed in with write access to the monorepo, and that git, jq and curl are installed.
2. Install the CLI and start Tares.
3. In a second terminal, start the MCP endpoint every crew session shares.
4. Give Tares access to GitHub under Settings > GitHub, so it can read each pull request, its CI and its merge state. On Tares Cloud you sign in with tares login and choose Connect GitHub instead, and there is no MCP endpoint to start.
5. Bring up the crew.
6. Plan the project from the monorepo, or from a folder that holds it.

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up

tares mcp --transport streamable-http

tares factory crew up
tares factory spec "what you want to build"

The spec interview writes the plan into a Tares project with milestones, tickets and an AGENTS.md, then asks whether to hand it to the crew. Say yes, and the orchestrator starts builders for it.

To see the branches and pull requests as they appear, run tares factory projects for each project’s progress, builders and repos. Run tares factory crew status for the stations and a line per project. The Crew page in the console also lists the pull requests waiting for review.

What you get

• Every change in the monorepo lives on a builder’s own branch until it is reviewed, so the default branch only receives work that has passed.
• Every pull request gets the reviewer’s verdict, posted on the pull request itself.
• A merge needs a passed review and green CI, or your own yes if you set the project to wait for it.
• The plan, tickets, reviews and your answers stay on Tares, so a crew that restarts picks up from the existing branches and pull requests.
• You can follow the state of each ticket’s pull request on the Crew page instead of watching terminals.
• tares factory doctor checks everything the crew needs. It also reads each handed-over repo’s languages from its manifests, at the repo root or one folder down, and tells you whether Claude Code has a language server for each.

When something else fits

• If the change is small and you want to drive it yourself, run tares factory session to work in your own Claude Code session, still bound to the project on Tares.
• If you want a person to approve every merge in one project, set that project to wait for your yes. The branch and pull request flow stays the same.
• If you need a second model to check each commit, the crew settings offer it, and tares factory crew up asks about it the first time.

Related