How do I write a spec a Claude Code crew can build test coverage from in a Node/TypeScript app?

Tares writes the spec with you: run tares factory spec in your Node/TypeScript repo and answer the interview about test coverage. /tares:spec asks one question at a time, has a second model attack the plan, and saves a Tares project with the spec, milestones, tickets and an AGENTS.md. You then hand the project to the crew, and builders turn the tickets into pull requests merged on main.

How it works

You do not write the spec file by hand. You describe the goal, and /tares:spec interviews you. The Get started page has the full setup.

• One question at a time. Each question waits for your answer before the next one. Say what you want covered, in your own words. For a Node/TypeScript app, that usually means which modules or folders matter most, which test runner the repo already uses, and what counts as done for each milestone.
• A second model attacks the plan. Before anything is saved, another model challenges the plan, so gaps show up while they are cheap to fix.
• The plan lands in a Tares project. You get:
  • the spec
  • milestones, each with acceptance checks
  • tickets, each with a working doc
  • an AGENTS.md
• The hand-over is your call. The session ends by asking whether to give the project to the crew. If you say yes, the orchestrator picks it up.

The crew is an orchestrator, a reviewer and builders, all Claude Code sessions on your machine. Builders are started one per milestone and repo. Each builder takes a ticket, works on its own branch and opens a pull request. The reviewer reviews every pull request to a fixed bar. A builder merges once the reviewer passes it and CI is green.

Tares keeps the plan, tickets, reviews, the assumptions the crew made, and your answers. If a session restarts, the crew carries on from that record.

Set it up

1. Check the prerequisites: Claude Code signed in on a plan that allows background sessions, gh signed in with write access to the repo, and git, jq and curl installed.
2. Install the CLI and point it at Tares. Locally, start Tares with tares up, then start the MCP endpoint in a second terminal. On Tares Cloud, run tares login and pick your workspace instead, and skip the MCP step.
3. Give Tares access to GitHub so it can read pull request, CI and merge state. Use Settings > GitHub on a local Tares, or Connect GitHub on Tares Cloud.
4. Bring up the crew. The first run asks how far the crew may go, such as whether it merges on its own after review and green CI, and how many builders run at once.
5. In your app’s repo, start the interview with your idea:

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up
tares mcp --transport streamable-http
tares login
tares factory crew up
tares factory spec "what you want to build"

Run tares up and tares mcp locally, or tares login for Tares Cloud, not both. For the idea, name the outcome in plain terms, for example that you want test coverage added to the checkout and orders modules of your TypeScript app.

6. Answer the questions as they come. When you want a milestone to be checkable, give the interview something concrete to turn into an acceptance check, such as the command that runs the tests and the folders that must be covered.
7. When the interview asks whether to hand the project to the crew, say yes.

If the repo has a tsconfig.json or a package.json, tares factory doctor checks whether Claude Code has a language server for it. Builders and the reviewer search less without one. tares factory crew up offers to install what is missing and installs only when you say yes.

What you get

• A Tares project holding the spec, milestones with acceptance checks, and tickets with a working doc each.
• An AGENTS.md that your sessions share, so builders start from the same written ground rules.
• A plan that a second model has already challenged before any code is written.
• Pull requests per ticket, each reviewed to a fixed bar and merged on main once the reviewer passes it and CI is green.
• A written record of every assumption the crew made on its own, so you check them at the end of a milestone instead of during every step.
• Questions that reach you one at a time in the orchestrator’s session, each with a recommendation. The Crew page in the Tares console shows the open question, the builders and the pull requests waiting for review.

You can also keep the tickets in Linear or GitHub Issues instead of Tares. Sessions change them there, and Tares only reads them.

When something else fits

• For a small piece of work, use tares factory session with your idea. It plans a short spec and builds it in your own Claude Code session, and offers the full spec and crew hand-over if the plan turns out big.
• The factory is built for solo developers and very small teams working with Claude Code on one machine, against their own GitHub repos. If that is not your setup, it is not the right fit today.

Related