How does the crew’s work on test coverage reach main?

Tares gets test coverage work onto main through a pull request. A builder works on its own branch and opens the pull request, the reviewer posts its verdict on it, and the builder merges once the reviewer passes it and CI is green. The same path applies to every ticket the crew handles, including a ticket about test coverage.

How it works

The software factory for Claude Code runs a crew of Claude Code sessions on your machine. A test coverage ticket moves through the crew like any other ticket:

• Orchestrator: hands the ticket to a builder. It is the only session you talk to.
• Builder: the orchestrator starts one per milestone and repo of a project. The builder takes the ticket, works on its own branch and opens a pull request. It pushes and opens the pull request with your gh login.
• Reviewer: reviews every pull request to a fixed bar and posts its verdict on the pull request.
• Merge: the builder merges the pull request once the reviewer passes it and CI is green. If the reviewer does not pass it, the builder does not merge.
• End state: a ticket ends at merged on main. A releaser, which tags and deploys, exists only if you ask for one.

Tares holds the record of all of this: the plan, the tickets and their stages, and every review. Tares reads the pull request, CI and merge state of every ticket itself, so the ticket’s stage follows what happens on GitHub. The sessions can restart and the record stays on Tares, so a crew that restarts carries on where it stopped.

The crew works on all your projects at once. While one project waits for you, the others carry on. Questions from every project reach you in the orchestrator’s session, one at a time.

Set it up

Follow these steps in order. The first run of crew up is where you choose how merges happen.

1. Check that Claude Code is signed in on a plan that allows background sessions. Check that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed.

gh auth login

2. Install the CLI.

uv tool install tares     # or: brew install glassflow/tap/tares

3. On a local Tares, start Tares, then start the MCP endpoint every crew session shares in a second terminal. Leave both running.

tares up
tares mcp --transport streamable-http

4. On Tares Cloud, sign in instead and pick your workspace in the browser. There is no MCP endpoint to start.

tares login

5. Give Tares access to GitHub, so it can read each pull request, its CI and its merge state. Use Settings > GitHub on a local Tares, or Connect GitHub on Tares Cloud. The GitHub connector page has both paths, and the Get started guide walks through the whole setup.
6. 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 (the recommended option) or waits for your yes. It also asks how many builders run at once.

tares factory crew up

7. Plan the work. Put the test coverage goal in the quotes in place of the example text, and run it in the repo the project builds on.

tares factory spec "what you want to build"

8. Say yes when asked whether to hand the project to the crew. The orchestrator picks it up, and builders start on the tickets.

Run tares factory doctor at any point to check everything the crew needs. Use tares factory crew status to see the stations and a line per project, and tares factory projects to see each project’s progress, builders and repos.

What you get

• Every change reaches main through a pull request that the reviewer has judged. The verdict is posted on the pull request itself.
• No change merges until the reviewer passes it and CI is green.
• Each builder works on its own branch, so builders on different tickets do not edit the same branch.
• You are not in the merge loop. With the recommended setting the crew merges on its own after review and green CI. You spend your time on the plan and on the few questions the crew cannot answer itself.
• The Crew page in the Tares console shows each project’s builders and the pull requests waiting for review. Locally it is at http://127.0.0.1:8787/crew.
• Every review and every choice the crew made on its own is kept on Tares, so you can check it at the end of each milestone instead of during every step.

When something else fits

• If you want a yes before every merge, choose the setting that waits for your yes when crew up asks. A single project can also wait for your yes before every merge while the rest of the crew merges on its own. tares factory crew halt stops merges, pushes and new sessions until tares factory crew resume.
• If the work is small, tares factory session lets you do it in your own Claude Code session on Tares, without the crew.

Related