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

Run tares factory spec in your Go service’s repo and Tares interviews you one question at a time, has a second model attack the plan, and writes a project the crew can build. The project holds the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md. You answer the questions for your internal refactors, and the crew builds the tickets into pull requests merged on main.

How it works

You do not write the spec by hand. /tares:spec (started by tares factory spec) opens Claude Code and runs the planning with you.

• One question at a time. The interview asks a single question, so you answer for your refactors in small steps instead of one long brief.
• A second model attacks the plan. Before anything is saved, a second model challenges the plan, so weak spots surface while you can still change them.
• The plan lands in a Tares project. You get the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md.
• You hand it over. The interview ends by asking whether to give the project to the crew. Say yes and the orchestrator picks it up.

The crew is an orchestrator, a reviewer and builders, with an optional releaser. Builders are started one per milestone and repo. Each takes a ticket, works on its own branch, opens a pull request, and merges it once the reviewer passes it and CI is green. Tares keeps the plan, the tickets, every review and your answers, so a crew that restarts carries on where it stopped.

For a Go service, tares factory doctor reads go.mod and checks whether Claude Code has a language server for Go. Builders and the reviewer search less when Claude Code can find a definition, its references and its callers through one.

Bring a few things to the interview so your answers make good milestones and tickets:

• The service and the packages the refactor touches.
• What each refactor should change inside the service.
• The checks you already trust, because milestones carry acceptance checks.
• Any decision you want to keep for yourself, because the crew asks you those one at a time, each with a recommendation.

Set it up

Follow these steps in order. The Get started page has the full walkthrough.

1. Check that Claude Code is signed in on a plan that allows background sessions. Sign in to gh with write access to the repos the crew works in, and make sure 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.

   tares up

   tares mcp --transport streamable-http

4. On Tares Cloud, sign in instead and pick your workspace in the browser. There is no MCP endpoint to start.

   tares login

5. Give Tares access to GitHub. On a local Tares use Settings > GitHub. On Tares Cloud choose Connect GitHub.

6. 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.

   tares factory crew up

7. From the root of your Go service, or a folder that holds its repos, start the interview and describe the refactors in your own words.

   tares factory spec "what you want to build"

8. Answer each question, read how the second model attacked the plan, and say yes when it asks whether to hand the project to the crew.

9. Open the orchestrator to answer the crew’s questions, and run the doctor if a station misbehaves.

   tares factory crew attach orchestrator

   tares factory doctor

What you get

• A Tares project with the spec, milestones with acceptance checks, and tickets that each have a working doc.
• An AGENTS.md that the crew’s sessions share.
• Pull requests from builders, each reviewed to a fixed bar by the reviewer and merged on main once CI is green.
• A record on Tares of the plan, the reviews, the assumptions the crew made, the questions it asked and your answers, so you check the crew’s choices at the end of each milestone instead of during every step.
• The Crew page in the Tares console, which shows the question waiting for you, each project’s builders and the pull requests waiting for review.

When something else fits

• For a small change you do not need a crew. tares factory session "<idea>" plans a small project and builds it in your own Claude Code session, still on Tares.
• If your tickets already live in Linear or GitHub Issues, keep them there. Tares reads them about once a minute and never writes to them.
• The crew runs on one machine, on your own Claude Code login and your own GitHub repos, so it fits solo developers and very small teams best.

Related