How does the reviewer decide a pull request for docs updates is good enough to merge?

In the Tares software factory for Claude Code, the reviewer posts a verdict on every pull request, and the merge happens once that 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 decides. A pull request for docs updates goes through this same loop as any other ticket.

How it works

The software factory for Claude Code splits the work into tickets. For each ticket, a builder makes a branch, does the work and opens a pull request. The reviewer reviews every pull request and posts its verdict. That verdict is what the merge gate reads.

The gate has two conditions:

• The reviewer’s verdict passes.
• CI is green.

When both hold, the builder merges. You choose how far the crew may go when you run crew up. In the walkthrough project, the crew merged on its own once the reviewer passed a pull request and CI was green. You can also set a project to wait for your yes before every merge. In that case each merge shows up as a question for you, and your answer is recorded as typed.

When the first round does not pass, the loop continues:

1. The reviewer asks for changes.
2. The builder makes them on the same pull request.
3. The reviewer reviews again, and the next round decides.

Most tickets pass on the first round. In the project followed on A project, end to end, two tickets needed a second round and both passed on it. While the builder waits, the project page shows a notice with its last message, for example that it is waiting for the reviewer’s verdict. Pull requests waiting for the reviewer sit in the review queue on the Crew page.

The reviewer can also report smaller issues outside the ticket it is reviewing. The orchestrator turns them into a new ticket, and that ticket gets its own pull request and its own review.

Set it up

1. Write the spec from your repo. Claude Code asks you questions, and the result goes into Tares as a spec, a plan, an AGENTS.md and milestones with acceptance checks. For a docs updates project, state in the spec what the finished docs must cover, so the checks have something to hold on to.

tares factory spec

2. Start the crew and choose how far it may go. This decides whether the crew merges by itself after a pass or waits for your yes.

tares factory crew up

3. Check the stations at any time.

tares factory crew status

4. Open the Crew page in the console, at http://127.0.0.1:8787/crew locally. The review queue lists pull requests waiting for the reviewer, and questions waiting for you appear at the top.
5. Open the project page and unfold Tickets. Each ticket shows its state (to do, in progress, in review, merged or blocked), the builder that held it, its pull request and its review rounds. A ticket on a second round is easy to spot there.
6. If you set the project to wait for your yes, answer the merge question in the orchestrator’s session. To steer the work, talk to the orchestrator.

New to the factory? Start with Get started.

What you get

• One verdict per review round, posted by the reviewer on the pull request, and a merge that follows a pass with green CI.
• A second round when the first fails. You do not restart anything, because the builder makes the requested changes and the reviewer reviews again.
• A record of every round. The Tickets fold keeps each ticket with its pull request and its review rounds, so you can see which docs pull requests passed first time and which needed changes.
• Extra findings turned into tickets. Smaller issues the reviewer spots are not lost, because the orchestrator adds a ticket for them and the plan grows by itself.
• Your say on merges. Choose automatic merging after a pass, or require your approval each time. Approvals are kept in the Decisions fold in your own words.
• Milestone checks. Each milestone carries acceptance checks, and at the end of each one the orchestrator brings you the assumptions the crew made along the way, so you can keep or reject them.

When something else fits

• If you want to read every pull request yourself before it merges, set the project to wait for your yes before every merge. The reviewer’s verdict still comes first.
• If a change needs a decision only you can make, such as a production fix outside the ticket, the crew flags it in the pull request and asks you rather than deciding alone.

Related