What should the reviewer check when a builder opens a pull request for bug fixes in a monorepo?
In Tares, the reviewer in the software factory for Claude Code reviews every builder pull request and posts a verdict. The builder merges once the verdict passes and CI is green. Read that verdict against the acceptance checks of the ticket’s milestone, then look at what the pull request flags.
How it works
The software factory for Claude Code works in a fixed loop, the same for every ticket. This is how a ticket reaches a merge:
- The builder takes one ticket at a time, makes a branch, does the work and opens a pull request.
- The reviewer reviews every pull request and posts its verdict.
- If the reviewer asks for changes, the builder makes them and a new review round follows. In the project walked through in A project, end to end, most tickets passed on the first round and two needed a second.
- Once the verdict passes and CI is green, the builder merges.
Each milestone in the plan carries acceptance checks, and each ticket sits in a milestone. In that project the work was a set of bugs in how a household app paid shifts. One milestone was “payout history stays as it was”: deactivating a sitter or changing a rate leaves past weeks as they were, and “today” is the household’s date. That is the kind of check you hold a bug fix to.
A project can change more than one repo. Its GitHub fold lists the repos it changes, where each is checked out, and their open and merged pull requests.
Set it up
- Start the spec in the repo with the bug fixes, and answer Claude Code’s questions. Put the behavior each fix must keep or restore into the milestone’s acceptance checks.
tares factory spec- Hand the project to the crew when the spec session asks. The orchestrator starts a builder for the first milestone.
- Bring the crew up when you have a project to hand it.
tares factory crew up- Open the Crew page in the console. Pull requests waiting for the reviewer appear in the review queue.
- Open the project page and the Tickets fold. For each ticket you see the builder that held it, its pull request and its review rounds. Read the milestone’s acceptance checks next to the verdict.
- Read the pull request description for flagged choices. When the crew meets something the plan does not cover, it picks a sensible answer and records it as an assumption. In the walked-through project, the builder left existing production data alone, flagged it in the pull request, and left any production fix to the person.
- Check the Assumptions fold at the end of the milestone. The orchestrator brings them to you in one question, and you keep or change each one.
What you get
- Every bug-fix pull request gets a reviewer verdict, and no merge happens before that verdict passes and CI is green.
- Each ticket shows its pull request and review rounds on the project page, so you can see how many passes a fix needed.
- Smaller issues the reviewer finds outside the ticket do not get lost. In the walked-through project they became a new ticket,
T8, placed in the milestone before the integration tests, and the builder fixed them there. - Choices the builder made on its own appear as assumptions, each with its tickets and the builder that made it, and you decide whether they stand.
- Your answers are kept under Decisions, in your own words, so the record of why a change went in stays with the project.
When something else fits
Decide how much of the merge you want to hold yourself. The How far the crew may go setting shows what you chose at crew up. In the walked-through project the crew merged on its own once the reviewer passed a pull request and CI was green. Another project waited for the person’s yes before every merge, so most of its decisions were merge approvals.
If you want to steer a ticket that is in progress, talk to the orchestrator. It answers the builders and brings you what needs you as a question in its session, and the project page lists those under questions waiting for you. If a fix needs a check the plan does not have, add it to the milestone’s acceptance checks so the next ticket is held to it.
If an assumption goes against what you want, say so in your answer. To make an answer stand from now on, say so for this project or for every project.