How do I write a spec a Claude Code crew can build small features from in a Go microservice?

Tares writes the spec with you: run tares factory spec in your Go repo and answer the /tares:spec interview, one question at a time. A second model attacks the plan, and Tares stores the result as a spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md. The crew then builds the tickets into pull requests merged on main. Setup follows Get started.

How it works

You do not write the spec by hand. /tares:spec runs it as a conversation in Claude Code, and the plan lands in a Tares project.

• The interview. It asks one question at a time. Describe the feature or service change in your own words and answer each question as it comes.
• The attack. A second model attacks the plan before it is final, so weak points in the plan surface while you can still change them.
• What lands in Tares. The spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md. The record stays on Tares, so a crew that restarts carries on where it stopped.
• The hand-over. The interview ends by asking whether to hand the project to the crew. If you say yes, the orchestrator picks it up.

The crew is an orchestrator, a reviewer and builders. The orchestrator starts one builder per milestone and repo. Each builder takes a ticket, works on its own branch, opens a pull request and merges it once the reviewer passes it and CI is green. The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request.

For Go, tares factory doctor reads go.mod in each handed-over repo and says whether Claude Code has a language server for Go. With one, builders and the reviewer can find a definition, its references and its callers, so they search less. If it is missing, doctor prints what to run, and tares factory crew up offers the same install and runs it only when you say yes.

Set it up

1. Check that Claude Code is signed in on a plan that allows background sessions, gh is signed in with write access to the repos the crew works in, and git, jq and curl are installed.

   gh auth login

2. Install the CLI.

   uv tool install tares     # or: brew install glassflow/tap/tares

3. On a local Tares, start Tares, then in a second terminal start the MCP endpoint every crew session shares. The crew reaches Tares only through this endpoint, so crew up and spec stop and tell you when it does not answer.

   tares up
   tares mcp --transport streamable-http

   On Tares Cloud, run tares login instead 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 Connect GitHub on Tares Cloud. Tares reads the pull request, CI and merge state of every ticket itself.

5. Bring up the crew. The first run asks how far the crew may go: whether it merges on its own after review and green CI or waits for your yes, whether it releases, whether a second model checks every commit, and how many builders run at once.

   tares factory crew up

6. Plan the project from your Go service repo, or from a folder that holds its repos. Put the change you want in the quoted idea.

   tares factory spec "what you want to build"

7. Answer the interview, then say yes to the hand-over. Questions from the crew reach you in the orchestrator’s session, one at a time, each with a recommendation.

   tares factory crew attach orchestrator

8. Run tares factory doctor to check the Go language server and everything else the crew needs.

What you get

• A Tares project that holds the spec, the milestones with acceptance checks, the tickets with a working doc each, and an AGENTS.md.
• Builders that each take one ticket onto its own branch and open a pull request. The reviewer holds every pull request to a fixed bar, and nothing merges until it passes and CI is green.
• A record on Tares of the plan, the tickets and their stages, every review, the assumptions the crew made, the questions it asked you and your answers. You check the crew’s own choices at the end of each milestone instead of during every step.
• The Crew page in the console, which shows the question waiting for you, the stations, each project’s builders and the pull requests waiting for review.
• Tickets that can live in Tares, in a Linear project or in GitHub Issues. Sessions change them with their own tools, and Tares only reads them.

When something else fits

• For one small change, run tares factory session "<idea>". It asks a few questions, writes a short spec and ticket list on Tares, and builds it in your own Claude Code session. If the plan turns out big, it offers the full spec and the hand-over to the crew.
• If you want to approve every merge on one project, set that project to wait for your yes, while the rest of the crew merges on its own.

Related