What should the reviewer check when a builder opens a pull request for bug fixes in a documentation website?

Tares has the reviewer read every builder pull request against its ticket and post a verdict, so for a docs site bug fix you check the ticket’s acceptance checks and CI. The reviewer also raises smaller issues it finds outside the ticket, and you check that the pull request flags any choice the builder made on its own. The whole record sits on the project page.

How it works

The software factory for Claude Code runs the same loop for every ticket, whatever the repo holds. For bug fixes in a documentation website that loop gives you these things to check:

• One ticket, one pull request. The builder works through the tickets one at a time. For each it makes a branch, does the work and opens a pull request. Check that the pull request fixes the bug in its ticket and nothing else.
• The ticket’s acceptance checks. Tickets belong to milestones, and each milestone carries acceptance checks. The project page shows them next to each ticket, its pull request and its review rounds. Compare the change with those checks.
• CI. The reviewer posts a verdict on every pull request. When the verdict passes and CI is green, the builder merges. In the example project, CI ran on every pull request from the first milestone on.
• Review rounds. If the reviewer asks for changes, the builder makes them and the next round decides. In the example project, two tickets took a second round and then passed.
• Findings outside the ticket. The reviewer can find smaller issues in code it is not reviewing for that ticket. The orchestrator turns them into a new ticket and places it in the milestone, and a builder fixes them there. Check that a pull request does not fold unrelated fixes into its own change.
• Assumptions. When the crew meets something the plan does not cover, it picks a sensible answer and records it as an assumption. The builder also flags it in the pull request. In the example project, a builder left existing data alone, flagged it in the pull request and left the production fix to the person. Check that each flagged choice is one you want to keep.
• The pull request description. The builder rewrote an existing description into the documented sections instead of appending to it. Read the description as the record of what changed and why.

Set it up

1. Run the spec session in your documentation repo. Claude Code asks you questions, a second model challenges the plan, and the result goes into Tares as a spec, a plan, an AGENTS.md for the project and milestones with acceptance checks.

tares factory spec

2. Write the acceptance checks for each bug fix in plain words. Name the page or behavior that is wrong and what correct looks like. If you want CI on every pull request, make that a check too, as the example project did in its first milestone.
3. Say yes to handing the project to the crew, then start the crew.

tares factory crew up

4. At crew up, choose how far the crew may go. The example project merged on its own once the reviewer passed and CI was green. Another project waited for the person’s yes before every merge. For bug fixes on a site you publish, you can choose to approve each merge yourself.
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. Questions that need you appear at the top.
6. Open the project page and unfold Tickets to read each ticket, its pull request and its review rounds. Unfold Assumptions to keep or change the crew’s own choices. Your answers stay on record under Decisions.

For the full walk through, see A project, end to end. If you are new to the factory, start with Get started.

What you get

• A review verdict on every bug-fix pull request, with the review rounds kept beside the ticket.
• Acceptance checks you wrote, shown next to the tickets they apply to.
• Smaller issues the reviewer finds outside a ticket, turned into a ticket of their own instead of being lost or slipped into the wrong pull request.
• A list of the choices the crew made on its own, each tied to its tickets and the builder that made it. The orchestrator brings them to you together at the end of each milestone.
• A record of every question the crew asked you and your answer in your own words.

When something else fits

• If you want to read every change before it lands, choose at crew up to have the project wait for your yes before each merge.
• If a fix needs a step only you can take on your machine, such as giving Tares a GitHub token, the crew asks you in the orchestrator’s session.
• To steer a ticket in progress, talk to the orchestrator.

Related