How do I make sure the reviewer checks pull requests against the tests in a Python backend?

Tares holds every pull request to the acceptance checks of its ticket, so you put your Python tests into those checks when you plan the project. The reviewer reviews each pull request and posts a verdict, and the builder merges only when the reviewer passes it and CI is green. You set the checks in tares factory spec, and the rest of the review and merge loop follows from them.

How it works

The software factory for Claude Code plans a project as milestones, and each milestone carries acceptance checks. Tickets sit under the milestones, and each ticket gets a builder.

• The builder takes one ticket at a time. It makes a branch, does the work and opens a pull request.
• The reviewer reviews every pull request and posts its verdict.
• When the verdict passes and CI is green, the builder merges. If the reviewer asks for changes, the builder makes them and a second review round follows.
• The reviewer can also find smaller issues outside the ticket. The orchestrator turns them into a new ticket and places it in the plan.

In the project walked through in A project, end to end, the first milestone was “tests and CI on the branch”: a test framework, unit tests for the logic that was broken, and a CI check on every pull request. That is the pattern to copy for a Python backend. Name your own test runner and the code it must cover.

How far the crew may go is a choice you make at crew up. In that project the crew merged on its own once the reviewer passed and CI was green. Another project waited for the person’s yes before every merge. The Crew page shows which one you chose under How far the crew may go.

Set it up

1. Finish the prerequisites in Get started: Claude Code signed in, gh signed in with write access to your repos, and git, jq and curl installed. Then install the CLI, start Tares and bring up the crew with tares factory crew up.
2. In your Python backend repo, plan the project:

tares factory spec "what you want to build"

3. Answer Claude Code’s questions. Say that every ticket must ship with tests for the behavior it changes, using the test runner your repo already uses. A second model challenges the plan before it goes into Tares.
4. Check the milestones that come out. Each should have acceptance checks that name the tests, for example that the new tests exist and pass, and that CI runs the test suite on every pull request. If a check is vague, tighten it before you hand the project over.
5. Open the project’s docs and read the AGENTS.md the spec session wrote. You can edit it under All docs, so add the testing expectations there too. Every session that builds the project reads it.
6. Hand the project to the crew when the spec session asks. Pick how far the crew may go at crew up: merge on its own after the reviewer passes and CI is green, or wait for your yes before each merge.
7. Follow the build in the console. Open the Crew page (http://127.0.0.1:8787/crew locally) to see the review queue, and open the project’s Tickets fold to see each ticket’s pull request and review rounds.

What you get

• Every pull request is reviewed against the ticket’s acceptance checks, and the verdict is recorded with the ticket.
• A merge needs two things together: a passing reviewer verdict and green CI. A pull request that fails either one does not merge.
• Review rounds are visible. Most tickets can pass on the first round, and when they do not, you see the requested changes and the round that passed.
• Problems the reviewer finds outside the ticket become new tickets in the plan instead of getting lost.
• Choices the crew makes where the plan is silent are recorded as assumptions, and the orchestrator brings them to you at the end of each milestone.
• The Decisions fold keeps every question the crew asked and your answer, such as a merge approval, in your own words.

When something else fits

• If you want to approve every merge yourself, choose that at crew up. The reviewer still posts a verdict, and the merge waits for your yes.
• If a pull request needs a check that no test or CI job covers, put it in the acceptance checks in plain words, or answer the crew’s question about it in the orchestrator’s session.

Related