How does the reviewer decide a pull request for dependency upgrades is good enough to merge?
Tares lets the builder merge a pull request once the reviewer’s verdict passes and CI is green. If the first round fails, the reviewer asks for changes, the builder makes them, and a second review round produces the next verdict. Each ticket records its review rounds, so you can see how a pull request got to merge.
How it works
The software factory for Claude Code splits the work between a builder and a reviewer. The A project, end to end walkthrough shows the gate on a real project.
- The builder opens the pull request. It works through the tickets one at a time. For each ticket it makes a branch, does the work and opens a pull request.
- The reviewer posts a verdict. The reviewer reviews every pull request and posts its verdict. Pull requests waiting for the reviewer appear in a review queue on the Crew page.
- The merge gate reads the verdict and CI. Once the verdict passes and CI is green, the builder merges. While the builder waits for the verdict, the project page shows a notice with its last message.
- A failed first round becomes a second round. The reviewer asks for changes, the builder makes them, and the next round is reviewed. In the walkthrough, most tickets passed on the first round. Two took a second round, and the second round passed.
- Findings outside the ticket become new work. When the reviewer finds smaller issues outside the ticket it is reviewing, the orchestrator turns them into a new ticket and places it in the plan. In the walkthrough, that ticket went into the second milestone before the integration tests.
You choose how far the crew may go when you run crew up. One option is that the crew merges on its own once the reviewer passes a pull request and CI is green. A project can instead wait for your yes before every merge, and each approval is recorded as a decision with your answer as typed.
Set it up
-
Start a spec in the repo that holds your dependency upgrades work and answer Claude Code’s questions. The result is a spec, a plan, an AGENTS.md for the project and milestones, each with acceptance checks.
tares factory spec -
Say yes when asked to hand the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.
-
Start the crew and choose how far it may go: merge on its own once the reviewer passes and CI is green, or wait for your yes before every merge.
tares factory crew up -
Answer the crew’s questions in the orchestrator’s session. Expect to trust the repo folder in Claude Code once, and to give Tares a GitHub token so it can read pull request, CI and merge state.
-
Open the Crew page at
http://127.0.0.1:8787/crewto see the review queue and what each station is doing. Open the project page and its Tickets fold to see each ticket’s pull request and review rounds. -
To steer the work, talk to the orchestrator. When the project is finished, stop the crew:
tares factory crew down
If you are new to the factory, start with Get started.
What you get
- A merge decision with a visible basis: the reviewer’s verdict plus green CI.
- A recorded review history. Each ticket shows the builder that held it, its pull request and its review rounds, so a pull request that needed two rounds is easy to spot.
- A second chance built into the flow. A failed first round sends the pull request back to the builder with the reviewer’s requested changes, and the next round gives a new verdict.
- Ticket states you can follow: to do, in progress, in review, merged or blocked. A blocked ticket names the tickets it waits for.
- A trail of your own calls. The Decisions fold holds every question the crew asked you, with your answer in your own words, and the Assumptions fold holds every choice the crew made on its own and whether you kept it.
- Extra tickets when the reviewer finds issues outside the one under review, so they get fixed inside the same project.
When something else fits
- If you want a human approval on every merge, choose the option where the project waits for your yes before each merge. The crew then asks you, and your answer is recorded as a decision.
- If you want to change the direction of the work mid-build, talk to the orchestrator rather than the reviewer.
- If this is your first project, read Get started before you hand work to the crew.