How many Claude Code sessions does a crew need for test coverage?

Tares does not set a session count for test coverage. The count follows the shape of your project: a crew is an orchestrator, a reviewer and one builder per milestone and repo, and for a small project one Claude Code session started with tares factory session can be enough. You put the coverage you want into the plan, and the sessions you run build it like any other work.

How it works

Test coverage is not a station of its own in the software factory for Claude Code. It is part of the work you plan, so the sessions you need depend on how that work is split.

A Tares crew has these members, and each is a Claude Code session running in the background on your machine:

• Orchestrator: hands out work, answers the others and brings you what needs you. It is the only session you talk to.
• Reviewer: reviews every pull request to a fixed bar and posts its verdict on the pull request.
• Builders: one per milestone and repo of a project, started by the orchestrator. Each takes a ticket, works on its own branch, opens a pull request and merges it once the reviewer passes it and CI is green.
• Releaser: only if you ask for one. It tags and deploys.

The orchestrator and the reviewer serve every project you hand the crew. The builders are the part that grows: the orchestrator starts them per project, one per milestone and repo, up to the number of builders you allow at once. A project with one repo and one milestone has one builder. A project with three repos has a builder for each.

A crew is not the only way to work. In a single session of your own, Tares still holds the plan, your shared AGENTS.md and memory, and the session’s record lands on the project. That path suits a small project, including one where the job is to add tests to existing code.

Set it up

Pick the path that matches the size of the work, then write the coverage you want into the plan.

1. Check what you need: Claude Code signed in on a plan that allows background sessions, gh signed in with write access to your repos, and git, jq and curl. Install the CLI with uv tool install tares or brew install glassflow/tap/tares, then start Tares with tares up. The Get started page has the full setup.
2. For a small project, work in one session. Describe the idea, including the tests you want:

tares factory session "<idea>"      # plan a small project and build it right there
tares factory session <project>     # work on a planned project
tares factory session               # pick one, or start something new

For a new idea, the session asks a few questions, writes a short spec and a ticket list on Tares, then builds it. If the plan turns out big, it offers the full spec and the hand-over to the crew instead. 3. For a larger project, in a second terminal start the MCP endpoint every crew session shares, then bring up the crew:

tares mcp --transport streamable-http
tares factory crew up

On Tares Cloud, sign in with tares login instead and skip the MCP endpoint. 4. Plan the project and say what coverage you expect. The plan becomes a spec, milestones with acceptance checks, and tickets with a working doc each, so coverage targets belong in those:

tares factory spec "what you want to build"

5. Answer the crew’s questions in the orchestrator’s session, and run tares factory doctor whenever a station misbehaves:

tares factory crew attach orchestrator

What you get

• A session count that matches the work. One session for a small project, or an orchestrator, a reviewer and as many builders as the project has milestones and repos, within the limit you set.
• Review on every pull request. The reviewer holds each change to a fixed bar and posts its verdict on the pull request, and a builder merges only after the reviewer passes it and CI is green.
• One place to talk. You answer questions in the orchestrator’s session, one at a time, each with a recommendation, and follow progress on the Crew page of the Tares console.
• A record that survives restarts. Tares keeps the plan, tickets, reviews, assumptions and your answers, so a crew that restarts carries on where it stopped.
• Room to grow. If a project you started in a single session gets bigger, you can hand it to the crew. If the crew has a project and you want to take it over, say yes when tares factory session asks. The builders push what they have and write their progress, and your session carries on from their branches and pull requests.

When something else fits

• Use a single session through tares factory session when the project is small, such as adding tests to one repo, and you want to drive it yourself.
• Use the crew when the work spans several milestones or repos, or when you want builders working in parallel with a reviewer checking every pull request while you answer only the questions that are yours.

Related