Who writes the spec when the work is small features?

Tares writes it with you in a spec session. You run tares factory spec in the repo, answer Claude Code’s questions one at a time, 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, so you do not draft a spec by hand.

How it works

The spec session is an interview. You start it in the repo and Claude Code asks you questions one at a time. A second model challenges the plan before it is final. The result goes into Tares as a set of documents:

• The spec, a short statement of what you want, such as “make the Babysitters PR mergeable”.
• The plan.
• The project’s AGENTS.md.
• Milestones, each with acceptance checks.

In the worked example on A project, end to end, the spec session produced three milestones. M1 covered tests and CI on the branch, M2 kept payout history as it was, and M3 covered merge and deploy. Each milestone carried its own acceptance checks.

When the interview ends, the session asks whether to hand the project to the crew. You say yes, the orchestrator picks the project up, and it starts a builder for the first milestone. Each builder works through its tickets one at a time, makes a branch, does the work and opens a pull request. The reviewer reviews every pull request, and the builder merges once the verdict passes and CI is green.

Set it up

Start from Get started if the factory is new to you. The order below is the same on every setup, and you skip a step you have already done.

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 brew install glassflow/tap/tares.
3. On a local Tares, start it with tares up. In a second terminal, start the MCP endpoint every crew session shares with tares mcp --transport streamable-http. On Tares Cloud, run tares login and pick your workspace in the browser. There is no MCP endpoint to start.
4. Give Tares access to GitHub: in Settings > GitHub for a local Tares, or with Connect GitHub on Tares Cloud.
5. Bring up the crew with tares factory crew up.
6. In the repo, plan the work by running the spec command with a short description of the features you want:

tares factory spec "what you want to build"

7. Answer each question. When the session finishes, say yes to hand the project to the crew.

After that, open the project page in the console. The Docs fold holds the starting prompt, the spec, the plan and the project’s AGENTS.md. You can edit any of them there.

What you get

• A written spec without writing it yourself. You answer questions in your own words and the session turns them into the documents.
• Milestones with acceptance checks. Each milestone says what done looks like before any builder starts.
• One shared set of documents. Every session that builds the project reads the starting prompt, the spec, the plan and the project’s AGENTS.md, which the spec session wrote.
• A record you can open. The project page keeps the docs, the tickets with their milestones, and every question the crew asked you with your answer, so you can see what the crew built from.
• A plan that can grow. In the worked example the reviewer found smaller issues outside the ticket it was reviewing. The orchestrator turned them into a new ticket and placed it in a milestone, so the plan grew by one ticket without a new spec.

When something else fits

• If you want to steer a running project, talk to the orchestrator. Its session is where you answer the crew’s questions and bring up changes.
• If you already have a spec you trust, you can edit the spec and plan in the Docs fold of the project page instead of answering the interview again.
• To pick up a finished project, hand it to the crew again, for example with a follow-up spec.

Related