How can I get Claude Code to take on test coverage on its own, with every change reviewed before it merges?

Tares runs a software factory for Claude Code that turns a test coverage goal into tickets, builds each one as a pull request, and merges only after a reviewer passes it and CI is green. You describe the goal once with tares factory spec, and the crew works through the ticket list. The kind of work shapes that list: for test coverage, you write the goal as milestones with acceptance checks and tickets that each end in one reviewable pull request.

How it works

A software factory for Claude Code is a crew of Claude Code sessions running in the background on your machine: an orchestrator, a reviewer and builders. Tares holds the plan, the tickets, every review and your answers, so a crew that restarts carries on where it stopped. New to this? Start with Get started.

The ticket list comes from the spec session. It interviews you one question at a time, has a second model attack the plan, and writes a Tares project: the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md. For test coverage, that is where you say what to cover and what done looks like.

• One ticket is one pull request. A builder takes a ticket, works on its own branch, opens a pull request, and merges it once the reviewer passes it and CI is green. The size of a ticket is therefore the size of a review.
• Milestones carry the acceptance checks. In the worked example, the first milestone was tests and CI on the branch: Vitest, unit tests for the babysitting logic, and a CI check on every pull request.
• The reviewer holds every pull request to a fixed bar and posts its verdict on the pull request. Nothing merges until it passes.
• The ticket list can grow. In the example, the reviewer found smaller issues outside the ticket it was reviewing. The orchestrator turned them into a new ticket and placed it before the integration tests, so the plan grew by one ticket on its own.

When the crew meets something the plan does not cover, it picks a sensible answer and writes it down as an assumption. In the example, the working doc named a config file that failed to load on the repo’s Node version, so the builder used a different file name and recorded that choice. At the end of each milestone, the orchestrator asks you whether to keep the assumptions.

Set it up

1. Check what you need: Claude Code signed in on a plan that allows background sessions, gh signed in with write access to the repos, plus git, jq and curl.

2. Install the CLI, start Tares, and in a second terminal start the MCP endpoint every crew session shares:

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up                  # console on http://127.0.0.1:8787
   tares mcp --transport streamable-http     # http://127.0.0.1:8788/mcp

3. Give Tares its own access to GitHub so it can read pull request, CI and merge state: on Tares Cloud choose Connect GitHub in your workspace settings, and locally add a token or App under Settings > GitHub. See Get started for both.

4. Bring up the crew. The first run asks how far the crew may go. Choose whether it merges on its own after review and green CI, or waits for your yes before every merge, and how many builders run at once.

   tares factory crew up

5. In the repo you want covered, plan the work. Name the modules, the kind of tests and the CI check you want, and ask for each ticket to be a small pull request that the reviewer can judge on its own:

   tares factory spec "what you want to build"

6. Answer the interview, then say yes when it asks whether to hand the project to the crew. Open the orchestrator to answer questions as they arrive:

   tares factory crew attach orchestrator

Follow progress on the Crew page of the console, and run tares factory doctor at any point to check what the crew needs.

What you get

• A project page with four steps, Spec, Build, Review and Done, and a progress bar with one segment per ticket.
• A pull request per ticket, each with its review rounds recorded. In the worked example, most tickets passed on the first round and two needed a second after the reviewer asked for changes. See A project, end to end for that project, which went from a spec to eight merged pull requests in about three hours.
• A Decisions fold with every question the crew asked you and your answers in your own words, and an Assumptions fold with every choice it made on its own.
• A record that stays on Tares, so you check choices at the end of each milestone instead of watching terminals.
• The option to wait for your yes before every merge on a project, even when the rest of the crew merges on its own.

When something else fits

• For a small, one-off coverage task, work in your own Claude Code session with tares factory session, which plans a small project and builds it there without the full crew.
• If you want to approve each change yourself, keep merges on your yes at crew up instead of letting the crew merge after review and green CI.
• The software factory is for solo developers and very small teams working on one machine with their own Claude Code login and GitHub repos.

Related