How does the reviewer decide a pull request for internal refactors 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 gate reads that verdict together with CI. When the verdict passes and CI is green, the builder merges. If the first round fails, the reviewer asks for changes, the builder makes them, and a second review round decides.

How it works

The software factory for Claude Code runs a crew: an orchestrator, builders and a reviewer. For each ticket, a builder makes a branch, does the work and opens a pull request. The reviewer then reviews the pull request and posts its verdict.

The merge gate reads two things:

• The reviewer’s verdict. It has to pass.
• CI. It has to be green. Tares reads pull request, CI and merge state through the GitHub access you give it.

When both hold, the builder merges.

How far the crew may go is your choice at crew up. In the project followed on A project, end to end, 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, and each approval was recorded as a decision. The Crew page shows which setting your crew runs under.

When the first round fails

1. The reviewer posts a verdict that asks for changes.
2. The builder makes the changes on the same ticket.
3. The reviewer reviews again. If that round passes and CI is green, the builder merges.

In the finished project, most tickets passed on the first round. Two tickets, T3 and T6, took a second round, and in both the second round passed. In a separate project that was still building, T4 also took two rounds and the second one passed.

The reviewer can also find smaller issues outside the ticket it is reviewing. The orchestrator turns those into a new ticket. In the finished project that was T8, placed in the milestone before the integration tests, so the plan grew by one ticket on its own.

Set it up

Follow the order in Get started. Claude Code must be signed in, gh must be signed in with write access to the repos the crew works in, and git, jq and curl must be installed.

1. Install the CLI.
2. On a local Tares, start Tares, then start the MCP endpoint that every crew session shares in a second terminal. On Tares Cloud, run tares login instead and pick your workspace in the browser. There is no MCP endpoint to start.
3. Give Tares access to GitHub: in Settings > GitHub for a local Tares, or with Connect GitHub on Tares Cloud. This is how Tares reads pull request, CI and merge state.
4. Bring up the crew and choose at crew up how far it may go, including whether it merges on its own after a pass.
5. Plan the project with tares factory spec. Describe the work you want done, and hand the project to the crew when you are asked.
6. Watch the rounds. Open the Crew page at http://127.0.0.1:8787/crew locally to see the review queue. Open the project page and its Tickets fold to see each ticket with its builder, its pull request and its review rounds.

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

On Tares Cloud, replace tares up and tares mcp --transport streamable-http with tares login.

What you get

• A verdict on every pull request before anything merges, with CI as the second condition.
• A built-in second round when the first one fails. The reviewer’s requested changes go back to the builder on the same ticket.
• A visible record. Each ticket shows its state (to do, in progress, in review, merged or blocked), its pull request and its review rounds. The Crew page lists pull requests waiting for the reviewer in a review queue.
• Follow-up tickets for smaller issues the reviewer spots outside the ticket under review.
• Your choice of gate. The crew either merges on its own after a pass and green CI, or waits for your yes before each merge.
• A project page with Decisions and Assumptions folds. Merge approvals and the choices the crew made on its own are written down there.

When something else fits

• If you want to approve every merge yourself, choose that at crew up. The crew then waits for your yes after the reviewer’s verdict.
• To see how a whole project moves from spec to done, read A project, end to end.

Related