How do I make sure the reviewer checks pull requests against the tests in a documentation website?

Tares holds every pull request to the acceptance checks you put on the ticket’s milestone, so you write your documentation website’s tests into the spec as acceptance checks. The reviewer reviews each pull request against them and posts a verdict. The builder merges only when the reviewer passes it and CI is green.

How it works

The software factory for Claude Code turns your spec into milestones, and each milestone carries acceptance checks. Tickets sit under those milestones, and the builder opens one pull request per ticket.

• Acceptance checks come from the spec. When you run tares factory spec in the repo, Claude Code asks you questions and a second model challenges the plan. The result goes into Tares as a spec, a plan, an AGENTS.md for the project and milestones, each with its acceptance checks.
• The reviewer reviews every pull request. It posts a verdict on each one. If it asks for changes, the builder makes them and the next round is reviewed again.
• CI is a second gate. The builder merges only once the verdict passes and CI is green. Tares reads pull request, CI and merge state through the GitHub access you give it.
• Findings turn into tickets. If the reviewer finds smaller issues outside the ticket it is reviewing, the orchestrator can turn them into a new ticket and place it in the plan.

The reviewer is only as strict as the checks you write. So name your documentation website’s tests in the spec, and have the plan add a CI check on every pull request, so the same tests gate each merge.

Set it up

1. Check that Claude Code is signed in, that gh is signed in with write access to the docs site repo, and that git, jq and curl are installed.
2. Install the CLI with uv tool install tares (or brew install glassflow/tap/tares). On a local Tares, run tares up, then start the MCP endpoint every crew session shares in a second terminal. On Tares Cloud, run tares login instead and pick your workspace in the browser.
3. Give Tares access to GitHub: Settings > GitHub on a local Tares, or Connect GitHub on Tares Cloud.
4. Bring up the crew. At crew up you choose how far the crew may go, including whether it merges on its own once the reviewer passes a pull request and CI is green.
5. Run tares factory spec in the docs site repo. When Claude Code asks what done looks like, state the tests as checks the reviewer must hold each pull request to. Ask for a CI check that runs them on every pull request, as the first milestone in the walkthrough does for its project (tests, plus a CI check on every pull request).
6. Say yes when asked to hand the project to the crew. Then open the project page and read the Tickets fold to confirm each milestone lists the checks you meant.

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

Run tares up and tares mcp in separate terminals on a local Tares, and skip both on Tares Cloud after tares login. The A project, end to end page follows one project from spec to merged pull requests, including review rounds. If you are new to the factory, start with Get started.

What you get

• Each ticket’s pull request is reviewed against the acceptance checks you wrote for its milestone, and the reviewer posts a verdict on every one.
• Merges wait for both a passing verdict and green CI. A pull request that fails either one does not merge.
• Review rounds are visible. In the Tickets fold you see each ticket with the builder that held it, its pull request and its review rounds. In the walkthrough project, most tickets passed on the first round, and two needed a second after the reviewer asked for changes.
• Extra problems the reviewer spots become tickets in the plan instead of being lost.
• Choices the crew made on its own, where the plan did not cover something, are recorded as assumptions. You are asked at the end of each milestone whether to keep them.
• The Crew page shows the review queue, so you see which pull requests are waiting for the reviewer.

When something else fits

• If you want a person to approve every merge, choose that when you set how far the crew may go. The walkthrough shows one project that waits for the person’s yes before each merge, and each approval is recorded under Decisions.
• If your docs site has no tests or CI yet, make adding them the first milestone, so later pull requests have something to be held to.
• For a one-off change you want to review yourself, a plain pull request without the crew is simpler.

Related