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

Tares plans the work for you: run tares factory spec in your Go microservice’s repo and /tares:spec interviews you one question at a time about the bug fixes. A second model attacks the plan, and Tares writes a project with the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md. You then hand the project to the crew, which builds the tickets into pull requests merged on main.

How it works

You do not write the spec by hand. /tares:spec runs it as a conversation and records the result on Tares.

• The interview. Claude Code asks one question at a time. Your answers are where the bug fixes and your Go service enter the plan: which bugs, which behavior is wrong, and what done looks like.
• The attack. A second model attacks the plan before anything is written, so weak points surface while they are cheap to change.
• What lands in Tares. A Tares project holds the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md.
• The hand-over. The interview 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. Builders are started per milestone and repo. Each takes a ticket, works on its own branch and opens a pull request. The reviewer reviews every pull request to a fixed bar, and a builder merges only once the reviewer passes it and CI is green. Tares keeps the plan, tickets, reviews and your answers, so a crew that restarts carries on where it stopped.

If you work a project in your own Claude Code session with tares factory session, your shared AGENTS.md and memory apply to that session.

Set it up

Follow these steps in order. Steps marked local apply to a local Tares, and the step marked cloud applies to Tares Cloud.

1. Check that Claude Code is signed in on a plan that allows background sessions, that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed. Optionally install the Codex CLI if you want a second model to check every commit.
2. Install the CLI.
3. Local: start Tares with tares up. The console is at http://127.0.0.1:8787.
4. Local: in a second terminal, start the MCP endpoint every crew session shares with tares mcp --transport streamable-http.
5. Cloud: run tares login and pick your workspace in the browser. There is no MCP endpoint to start.
6. Give Tares access to GitHub. On a local Tares add a token or App under Settings > GitHub. On Tares Cloud choose Connect GitHub. Tares reads the pull request, CI and merge state of every ticket itself.
7. 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.
8. Open a terminal in your Go microservice’s repo and plan the project.

uv tool install tares     # or: brew install glassflow/tap/tares
tares up                  # console on http://127.0.0.1:8787
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

Replace the quoted text with a plain description of the bug fixes you want, then answer each question as it comes. When the interview asks whether to hand the project to the crew, say yes. Answer the crew’s later questions in the orchestrator’s session with tares factory crew attach orchestrator. They arrive one at a time, each with a recommendation. Run tares factory doctor at any point to check everything the crew needs. For the full walkthrough see Get started.

What you get

• A Tares project with a spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md, all produced from one interview.
• A plan that a second model has already attacked before the crew starts building.
• Pull requests for each ticket, reviewed to a fixed bar and merged on main once CI is green. If you want a human gate, a single project can wait for your yes before every merge.
• A written record of every assumption the crew made, so you can check its choices at the end of each milestone instead of during every step.
• Questions that reach you one at a time, and a Crew page in the console that shows progress, builders and pull requests waiting for review.

When something else fits

• For a small fix you want to build right away, run tares factory session with your idea. It plans a short spec and ticket list and builds in your own Claude Code session, and it offers the full spec and crew hand-over if the plan turns out big.
• If your tickets already live in Linear or GitHub Issues, keep them there. Sessions change them with their own tools and Tares only reads them.

Related