Who writes the spec when the work is test coverage?

Tares writes it with you in a spec session. You run tares factory spec in the repo and answer Claude Code’s questions, and the session writes the spec, the plan, the project’s AGENTS.md and the milestones with their acceptance checks. The crew then builds from those documents. Test coverage work goes through the same session as any other project.

How it works

The spec session is where the project is defined, and you take part in it.

• You run tares factory spec in the repo. Claude Code interviews you, one question at a time, about what you want covered.
• A second model challenges the plan before it is final.
• The result goes into Tares as four things: a spec, a plan, an AGENTS.md for the project, and milestones, each with acceptance checks.
• At the end, you say yes to handing the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.

For test coverage, the milestones describe the tests and how to know they are done. In the worked example in A project, end to end, a pull request had no tests and a few bugs. The spec session produced a spec called “make the Babysitters PR mergeable” and three milestones. The first, “tests and CI on the branch”, covered Vitest, unit tests for the babysitting logic and a CI check on every pull request.

The builders do not write the spec. They work from it, one ticket at a time, each with a branch and a pull request that the reviewer checks. If the crew meets something the plan did not cover, it picks a sensible answer and records it as an assumption. At the end of each milestone it asks you whether to keep those assumptions.

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, and that git, jq and curl are installed.
2. Install the CLI with uv tool install tares, or with brew install glassflow/tap/tares.
3. On a local Tares, start Tares with tares up. In a second terminal, start the MCP endpoint every crew session shares with tares mcp --transport streamable-http.
4. On Tares Cloud, run tares login and pick your workspace in the browser. There is no MCP endpoint to start.
5. Give Tares access to GitHub, in Settings > GitHub for a local Tares or with Connect GitHub on Tares Cloud.
6. Bring up the crew, then plan the project from the repo you want to cover with tests.

tares factory crew up
tares factory spec "add unit tests and a CI check for the billing module"

7. Answer the questions in the spec session. When the spec, plan and milestones look right, say yes to hand the project to the crew.

New to the factory? Start with Get started.

What you get

• A spec that states the test coverage goal in your words, plus a plan to reach it.
• An AGENTS.md for the project, which every session that builds the project reads.
• Milestones with acceptance checks, so each step of the coverage work has a clear point where it is done.
• A project page where the Docs fold holds the starting prompt, the spec, the plan and the AGENTS.md. You can edit any of them in All docs.
• A Tickets fold that shows each ticket with its builder, its pull request and its review rounds.
• A Decisions fold that records every question the crew asked you and your answer, and an Assumptions fold for the choices the crew made on its own, with whether you kept them.
• A reviewer that checks every pull request. In the worked example, the reviewer also found smaller issues outside the ticket it was reviewing, and the orchestrator turned them into a new ticket.

When something else fits

• To change direction after the build starts, talk to the orchestrator. It answers the builders and brings you what needs your decision.
• To pick up a finished project again, hand it to the crew again, for example with a follow-up spec.

Related