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

Tares has the reviewer check each pull request against its ticket and the acceptance checks of the milestone the ticket belongs to, then post a verdict. The builder merges once the verdict passes and CI is green. For small features in a Go microservice, you add the repo’s own rules to the project’s AGENTS.md and write acceptance checks that name the behavior to prove.

How it works

The software factory for Claude Code splits a project into milestones, and each milestone carries acceptance checks. Each milestone holds tickets, and the builder works through them one at a time. For each ticket it makes a branch, does the work and opens a pull request.

The reviewer reviews every pull request and posts its verdict. That gives a fixed bar for each pull request:

• The ticket and the milestone’s acceptance checks. The pull request has to deliver what the ticket says and satisfy the checks of its milestone.
• CI. The builder merges only when the verdict has passed and CI is green.
• Review rounds. If the reviewer asks for changes, the builder makes them and the next round decides. Most tickets pass on the first round, and some take a second.

Beyond that bar, the reviewer also looks for smaller issues outside the ticket in front of it. It does not widen the pull request. The orchestrator turns those findings into a new ticket, placed in the milestone where it belongs, and the builder fixes them there. In the project this is based on, that added one ticket to the plan on its own.

The spec session also writes an AGENTS.md for the project. Every session that builds the project reads it, and you can edit it from the project’s Docs fold. That is where the rules of your repo live. For a project like A project, end to end, the reviewer works from that record of spec, plan, tickets and acceptance checks.

Set it up

1. Plan the work with the spec command, so each small feature becomes its own ticket under a milestone with acceptance checks. If you are new to the factory, start with Get started.

tares factory spec "what you want to build"

2. Write the acceptance checks so the reviewer can test them. Name the behavior the feature adds, the tests that cover it, and the existing behavior that must stay as it was. One milestone in the example project reads “payout history stays as it was”, and another asks for tests and a CI check on every pull request.
3. Open the project’s AGENTS.md in the Docs fold and add the conventions of your Go service, such as how the service is built and tested and how packages are laid out. Every session that builds the project reads it.
4. Make sure CI runs on every pull request. The merge waits for a passing verdict and green CI, so a check that CI does not run cannot hold a merge.
5. Watch the reviewer’s queue from the Crew page, at http://127.0.0.1:8787/crew on a local Tares, or follow the crew from the terminal.

tares factory crew status

6. Open the Tickets fold on the project page to read each ticket with its pull request and review rounds. Answer any question the crew brings you in the orchestrator’s session.

What you get

• A consistent bar. Every small-feature pull request faces the same test: the ticket, the milestone’s acceptance checks and green CI.
• Small pull requests. The builder opens one pull request per ticket, so the reviewer reads one feature at a time.
• Findings that do not get lost. Issues the reviewer spots outside the ticket become their own ticket instead of growing the pull request.
• Visible choices. When the builder meets something the plan did not cover, it picks a sensible answer and records it as an assumption. It can also flag the choice in the pull request, as one builder did when it left existing production data alone and left the fix to the person. At the end of each milestone the orchestrator asks whether you keep the assumptions made in it.
• A record. The project page keeps each ticket’s builder, pull request and review rounds, and your answers in the Decisions fold.

When something else fits

• If you want to approve every merge yourself, say so. One project in the example waited for the person’s yes before every merge, and the merge approvals were recorded as decisions.
• If a change is not a small feature, such as a rewrite or a change across several repos, split it into milestones with their own acceptance checks first, so the reviewer has a clear bar for each part.

Related