How does the reviewer decide a pull request for small features is good enough to merge?

Tares has the reviewer in the software factory for Claude Code review every pull request and post a verdict, and the builder merges once the verdict passes and CI is green. If the first round does not pass, the reviewer asks for changes, the builder makes them, and a second review round decides again. Each ticket records its pull request and its review rounds, so you can see how it got to merge.

How it works

The software factory for Claude Code works ticket by ticket. The builder takes one ticket, makes a branch, does the work and opens a pull request. The reviewer then reviews that pull request and posts its verdict.

The merge gate reads two things:

• The reviewer’s verdict. It must pass.
• CI. It must be green.

When both hold, the builder merges. You choose how far the crew may go when you run crew up. In one project the crew merges on its own once the reviewer passes a pull request and CI is green. Another project waits for your yes before every merge, and each approval is kept as a decision with your answer as typed.

When the first round does not pass, the flow goes like this:

1. The reviewer asks for changes instead of passing the pull request.
2. The builder makes the changes on the same ticket.
3. The reviewer reviews again, and the next round passes.

In the project followed on A project, end to end, most tickets passed on the first round. Two took a second round, and a third ticket in another project did the same: the reviewer asked for changes, the builder made them and the second round passed.

While the builder waits for a verdict, the ticket shows as in review and a notice on the project page shows the builder’s last message. Pull requests waiting for the reviewer appear in a review queue on the Crew page.

Set it up

You do not configure the reviewer’s verdict itself. You bring up the crew, hand it a project, and the review and merge flow runs on every pull request. Follow the Get started page for the full setup. In short:

1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed.
2. Install the CLI with uv tool install tares (or brew install glassflow/tap/tares).
3. On a local Tares, start Tares with tares up. In a second terminal, start the MCP endpoint every crew session shares with tares mcp --transport streamable-http. On Tares Cloud, run tares login instead and pick your workspace in the browser.
4. Give Tares access to GitHub, so it can read pull request, CI and merge state.
5. Bring up the crew and choose how far it may go, including whether it merges on its own after a pass or waits for your yes.
6. Plan a project.

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

7. Open the Crew page in the console, http://127.0.0.1:8787/crew locally. The panel on how far the crew may go shows what you chose at crew up, and the review queue shows pull requests waiting for the reviewer.
8. Open the project page and unfold Tickets to follow each ticket, its pull request and its review rounds.

What you get

• A verdict on every pull request before it merges, posted by the reviewer.
• A merge that waits for both a passing verdict and green CI.
• A clear path from a failed first round to a second one: changes requested, changes made, review again.
• A record on the project page. The Tickets fold shows each ticket with the builder that held it, its pull request and its review rounds, and the ticket states are to do, in progress, in review, merged or blocked.
• Extra findings turned into work. When the reviewer finds smaller issues outside the ticket it is reviewing, the orchestrator turns them into a new ticket. In the example project that became T8, placed before the integration tests, and the builder fixed the issues there.
• Control over merging. You can let the crew merge on its own after a pass, or require your yes before every merge.

When something else fits

If you want to approve every merge yourself, choose that when you bring up the crew, and the project waits for your yes after the reviewer passes. If you want to steer the work while it runs, talk to the orchestrator, which answers the builders and brings you what needs you as a question in its session.

Related