How does the reviewer decide a pull request for test coverage is good enough to merge?

Tares has the reviewer review every pull request in the software factory for Claude Code and post a verdict. The merge gate reads that verdict together with CI. When the verdict passes and CI is green, the pull request merges. When the reviewer asks for changes, the builder makes them and a second review round decides.

How it works

The software factory for Claude Code splits the work between a builder and a reviewer. A test-coverage pull request goes through the same path as any other ticket.

• The builder works one ticket at a time. It makes a branch, does the work and opens a pull request.
• The reviewer reviews every pull request and posts its verdict.
• The merge gate needs two things: a passing verdict and green CI. Once both are true, the builder merges.
• If the verdict asks for changes, the builder makes them on the same pull request and the reviewer runs a second round. The ticket records each review round, so you can see whether it passed on the first or the second.

The acceptance checks come from the spec. When you hand a project to the crew, the spec session turns the goal into milestones, and each milestone carries acceptance checks. In the project that Tares documents end to end, the first milestone was tests and CI on the branch: Vitest, unit tests for the babysitting logic and a CI check on every pull request. That is the kind of work where the verdict and the CI result together decide the merge.

A first-round fail is a normal part of the flow. In that project most tickets passed on the first round. Two of them, T3 and T6, took a second round: the reviewer asked for changes, the builder made them and the next round passed. Another project mid-build showed the same pattern, where T4 took two rounds and the second one passed. The reviewer can also find smaller issues outside the ticket in front of it. The orchestrator turns those into a new ticket and places it in the plan, so they get fixed without blocking the pull request under review.

How far the crew may go is your choice at crew up. The Crew page shows it under How far the crew may go. In the documented 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 each merge showed up as a question in the Decisions fold.

Set it up

1. Start from the repo you want tested. Run the spec command and answer Claude Code’s questions. The spec, the plan and the milestones with their acceptance checks go into Tares.

   tares factory spec

2. Put the test and CI work into its own milestone, as the documented project did with tests and CI on the branch. Write its acceptance checks so the reviewer has a clear target for each pull request.

3. Say yes when the spec session asks whether to hand the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.

4. Choose how far the crew may go when you bring the crew up. Decide whether it merges on its own once the reviewer passes and CI is green, or waits for your yes before every merge.

   tares factory crew up

5. Open the Crew page in the console, at http://127.0.0.1:8787/crew locally. Pull requests waiting for the reviewer appear in a review queue, and questions waiting for you appear at the top.

6. Open the project page and unfold Tickets. Each ticket shows the builder that held it, its pull request and its review rounds. A ticket in a second round shows that the reviewer asked for changes and the builder is working on them.

7. To steer the work, talk to the orchestrator. It answers the builders and brings you what needs you, as a question in its session.

The full walkthrough is in A project, end to end. If you are new to the factory, start with Get started.

What you get

• One verdict per review round, posted on every pull request, so the merge decision is never implicit.
• A merge that waits for both a passing verdict and green CI.
• A second round when the first one asks for changes. The builder fixes the pull request and the reviewer looks again, with no manual handoff from you.
• A record of every review round on the ticket, next to the builder and the pull request.
• New tickets for smaller issues the reviewer finds outside the ticket under review, placed in the plan by the orchestrator.
• Control over merging. You can let the crew merge on its own after a pass, or approve every merge yourself and see each approval in the Decisions fold with your answer as typed.

When something else fits

• If you want a person to read every test pull request before it merges, set the crew to wait for your yes before each merge. The reviewer’s verdict still comes first, and you decide after it.
• If a change needs a judgment that only you can make, such as touching production data, expect the builder to flag it in the pull request and leave that decision to you.

Related