What happens when the reviewer asks for changes to docs updates?

Tares sends the pull request back to the builder when the reviewer asks for changes, and the builder makes them so a second review round can pass. Smaller findings the reviewer spots outside the ticket become a new ticket instead of stretching the pull request. You see every round on the project page.

How it works

The software factory for Claude Code reviews every pull request the same way, so a pull request for docs updates follows the loop below.

• The builder works one ticket at a time. It makes a branch, does the work and opens a pull request.
• The reviewer reviews the pull request and posts its verdict.
• If the reviewer asks for changes, the builder makes them and the pull request goes into a second round.
• Once the verdict passes and CI is green, the builder merges. If you chose a stricter setting, the crew waits for your yes before each merge.

In the project followed on A project, end to end, most tickets passed on the first round. Two tickets, T3 and T6, took a second round: the reviewer asked for changes, the builder made them, and the next round passed.

The reviewer also looks beyond the ticket in front of it. When it finds smaller issues outside that ticket, the orchestrator turns them into a new ticket. In that project the new ticket was T8. The orchestrator placed it in the second milestone, before the integration tests, and the builder fixed the issues there. The plan grew by one ticket on its own, and the original pull request stayed focused on its own ticket.

The orchestrator records that choice as an assumption. At the end of the milestone it brings you its assumptions in one question, and you decide whether to keep them.

Set it up

You do not configure review rounds. They are part of how the crew runs once a project is handed over. To get a crew running, follow the order from Get started.

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 it with tares up. In a second terminal, start the MCP endpoint every crew session shares. On Tares Cloud, run tares login instead and pick your workspace in the browser.
4. Give Tares access to GitHub: in Settings > GitHub for a local Tares, or with Connect GitHub on Tares Cloud.
5. Bring up the crew, then plan a project.

gh auth login
tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

6. Open the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares. Pull requests waiting for the reviewer appear in a review queue, and questions waiting for you appear at the top.
7. 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 review shows that state, and a ticket that needed a second round shows both rounds.
8. Unfold Assumptions to see the new ticket that came from the reviewer’s smaller findings. Answer the orchestrator’s question at the end of the milestone to keep or change those choices.

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

What you get

• A second pass without you in the middle. The reviewer asks for changes, the builder makes them, and the next round passes before the merge.
• A clear record. The Tickets fold keeps each ticket’s pull request and its review rounds, so you can see which tickets needed more than one.
• Findings that do not get lost. Smaller issues outside the ticket become their own ticket in the plan, with a place in the milestone order.
• A say in what stays. Each new ticket from a finding is listed as an assumption, with the tickets it touches and the builder that made it, and you keep or change it at the end of the milestone.
• Control over merging. At crew up you choose how far the crew may go, for example merging on its own once the reviewer passes and CI is green, or waiting for your yes. The Crew page shows what you chose.

When something else fits

• If you want to change the direction of a ticket yourself rather than wait for a review round, talk to the orchestrator. It owns the plan and the builders.
• If a finding is something only you can decide, expect the orchestrator to ask you as a question in its session. The Decisions fold keeps your answer in your own words.

Related