What should the reviewer check when a builder opens a pull request for small features in a Python backend?

Tares has the reviewer review every pull request a builder opens and post a verdict, and the builder merges once the verdict passes and CI is green. For small features in a Python backend, you read that verdict next to the acceptance checks of the ticket’s milestone, the CI result, and anything the builder flagged in the pull request. The project page in the console shows all of these in one place.

How it works

The software factory for Claude Code runs each ticket the same way, whatever the repo:

• The builder works through the tickets one at a time. For each, it makes a branch, does the work and opens a pull request.
• The reviewer reviews every pull request and posts its verdict.
• Once the verdict passes and CI is green, the builder merges.
• If the reviewer asks for changes, the builder makes them and the next round is reviewed. Each round is recorded on the ticket.

The spec session turns your plan into milestones, and each milestone carries acceptance checks. The Tickets fold on the project page lists each ticket with the builder that held it, its pull request and its review rounds, so you can set a pull request beside the checks of its milestone.

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 and places it in the plan, so the original pull request stays on its own scope.

Set it up

1. Bring up the crew and plan the small feature. The spec session ends with a spec, a plan, an AGENTS.md and milestones, each with acceptance checks.

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

2. Read the acceptance checks of each milestone before the crew starts. For a small feature, make them concrete: the behavior the endpoint or service function must show, and whether tests and a CI check on every pull request are part of the milestone. The example project’s first milestone did exactly that, with unit tests and a CI check on every pull request.
3. Open the project’s Docs fold and edit its AGENTS.md. Every session that builds the project reads it. The software factory for Claude Code treats a Python backend like any other repo, so put your repo’s conventions there, such as how you run tests and what style you expect.
4. Open the project page. Locally, the Crew page is at http://127.0.0.1:8787/crew. For each pull request in the Tickets fold, check these points:
   • The pull request meets the acceptance checks of its milestone.
   • CI is green, because the builder merges only on a passing verdict and green CI.
   • The change stays inside the ticket. Stray findings belong in a new ticket, as in the example project.
   • Choices on existing data are flagged in the pull request. In the example, the builder left existing data alone, flagged it in the pull request and left any production fix to the person.
5. Watch the Assumptions fold. When the crew meets something the plan did not cover, it picks a sensible answer and records it as an assumption. At the end of each milestone the orchestrator asks you whether to keep them.

For the full path from spec to done, see A project, end to end. If you are new to the factory, start with Get started.

What you get

• A verdict on every pull request before it merges, with the review rounds kept on the ticket.
• Merges gated on a passing verdict and green CI.
• Acceptance checks per milestone, visible next to each ticket and its pull request.
• Small findings outside a ticket turned into their own ticket instead of widening the pull request.
• Every choice the crew made on its own recorded as an assumption, with the tickets it touches and the builder that made it.
• Your answers to the crew’s questions kept in the Decisions fold, in your own words.

When something else fits

• If you want to approve each merge yourself, say so. The example’s second project waited for the person’s yes before every merge, so its decisions were mostly merge approvals.
• If a change is large, split it into more tickets and milestones so each pull request has acceptance checks you can verify.
• If the plan itself is unclear, steer the work by talking to the orchestrator rather than in the pull request.

Related