How do I get Claude Code to ship test coverage from tickets that live in Tares itself?

Tares turns a test coverage goal into tickets stored in Tares, each with acceptance checks and a working doc, and a crew of Claude Code sessions builds them into merged pull requests. You describe the goal with tares factory spec, answer the interview, and hand the project to the crew. Builders take the tickets one at a time, a reviewer holds each pull request to a fixed bar, and a ticket merges once the review passes and CI is green.

How it works

Tickets live in Tares by default, so there is nothing to connect. When you run tares factory spec, Claude Code interviews you one question at a time, a second model challenges the plan, and the result is written into a Tares project:

• a spec and a plan
• milestones, each with acceptance checks
• tickets, each with a working doc
• an AGENTS.md for the project

For test coverage, shape the milestones around what “covered” means to you. In a real project 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. A later milestone covered a behavior the tests had to protect.

When you hand the project over, the orchestrator starts a builder for a milestone. The builder works through the tickets 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. A blocked ticket names the tickets it waits for, which keeps the order you planned. If the reviewer finds smaller issues outside the ticket, the orchestrator can turn them into a new ticket and place it before the work that depends on it.

The working doc is the builder’s brief for its ticket. Put the test framework, config file names, the Node or language version and the CI job there. When the crew meets something the plan did not cover, it picks a sensible answer, records it as an assumption and carries on. You review the assumptions at the end of each milestone.

Set it up

1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in (gh auth login), and that git, jq and curl are installed.
2. Install the CLI and start Tares locally. On Tares Cloud, run tares login instead and skip the MCP step.
3. In a second terminal on a local Tares, start the MCP endpoint every crew session shares.
4. Give Tares access to GitHub, under Settings > GitHub on a local Tares or with Connect GitHub on Tares Cloud. Tares reads the pull request, CI and merge state of every ticket itself.
5. Bring up the crew, then plan the project from the repo you want covered.

uv tool install tares     # or: brew install glassflow/tap/tares
tares up                  # console on http://127.0.0.1:8787
 
# second terminal
tares mcp --transport streamable-http
 
# third terminal
tares factory crew up
tares factory spec "unit tests for the billing module and a CI check on every pull request"

6. In the interview, state the coverage you want as checks you can verify: which modules, which test runner, and that CI runs the tests on every pull request. Name versions and config files in the working docs so builders do not guess.
7. When Claude Code asks whether to hand the project to the crew, say yes. The orchestrator picks it up.
8. Answer questions in the orchestrator’s session with tares factory crew attach orchestrator, and follow progress on the Crew page at http://127.0.0.1:8787/crew. Open the project page to see each ticket’s state: to do, in progress, in review, merged or blocked.

Run tares factory doctor at any point to check everything the crew needs. New to the crew? Get started covers each step in more detail.

What you get

• Pull requests merged on main, one per ticket, each reviewed to a fixed bar with CI green.
• A project page with milestones, their acceptance checks, and each ticket with its builder, pull request and review rounds.
• A record of every question the crew asked you and every assumption it made, so you check choices at the end of each milestone instead of during every step.
• Tickets that stay in order, because a blocked ticket names what it waits for and new tickets from review land where they belong.
• Crew restarts that lose nothing. The plan, tickets and answers stay on Tares, so a crew that restarts carries on where it stopped.

A project, end to end follows a test-and-fix project from spec to eight merged pull requests in about three hours, with five questions to the person along the way.

When something else fits

• If your tickets already live in Linear or GitHub Issues, keep them there. Sessions change them in those trackers and Tares reads them about once a minute.
• For a small test task that does not need a crew, run tares factory session to work on it in your own Claude Code session, still on Tares.

Related