How do I get Claude Code to ship internal refactors from tickets in Tares?

Tares keeps your refactor tickets, each with acceptance checks and a working doc, and a crew of Claude Code sessions builds them into pull requests merged on main. You describe the refactor with tares factory spec, and Tares records milestones with acceptance checks and a ticket with its own working doc for each step. Builders take the tickets one at a time, and a blocked ticket waits for the tickets it names.

How it works

Tares is the crew’s backbone. It holds the plan, the tickets and their stages, every review and your answers, so the tickets live in Tares by default and nothing else needs to track them.

• The spec session writes the tickets. tares factory spec opens Claude Code, interviews you one question at a time and has a second model challenge the plan. It writes a Tares project: the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md.
• Each ticket carries its own brief. The working doc sits with its ticket and is what a builder reads before it starts. Milestones hold the acceptance checks, so the bar for done is written down before any code changes.
• The crew picks tickets up in order. The orchestrator starts a builder per milestone and repo. A builder works through its tickets one at a time, each on its own branch, and opens a pull request. A ticket that depends on another shows as blocked and names the tickets it waits for.
• Review gates every merge. The reviewer reviews every pull request and posts a verdict. The builder merges once the verdict passes and CI is green.
• Surprises are written down. When the crew meets something the plan did not cover, it picks a sensible answer and records it as an assumption. At the end of each milestone the orchestrator brings you those assumptions in one question.

The record stays on Tares, so a crew that restarts carries on where it stopped.

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 you will refactor, and git, jq and curl are installed.

2. Install the CLI and start Tares locally. For Tares Cloud, run tares login instead and pick your workspace in the browser.

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

3. On a local Tares, start the MCP endpoint every crew session shares, in a second terminal. The crew reaches Tares only through it.

   tares mcp --transport streamable-http

4. 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. The Get started page has both paths.

5. Bring up the crew. The first run asks how far it may go, such as merging on its own after review and green CI, and how many builders run at once.

   tares factory crew up

6. Plan the refactor from the repo it changes. Name the refactor, the code it touches and what must stay true afterwards. When the interview asks, shape the tickets so each is one reviewable step.

   tares factory spec "what you want to build"

7. Check what the plan wrote. For each milestone, confirm the acceptance checks say how you will know it is done. For each ticket, confirm its working doc names the files, commands and constraints a builder needs. You can edit the docs in the project’s page in the console.

8. Say yes when asked to hand the project to the crew. Then answer its questions in the orchestrator’s session.

   tares factory crew attach orchestrator

Follow progress on the Crew page at http://127.0.0.1:8787/crew on a local Tares. The project page shows each ticket as to do, in progress, in review, merged or blocked, with its builder, pull request and review rounds. A project, end to end walks through one real build.

What you get

• Tickets that explain themselves. Each one has a working doc and sits under a milestone with acceptance checks, so a builder and the reviewer work from the same written bar.
• Work in a sensible order. Builders take tickets one at a time, and blocked tickets wait for the ones they depend on.
• Merged pull requests. Every change is reviewed to a fixed bar, and nothing merges until it passes and CI is green.
• Plans that adjust. In the example project, the reviewer found smaller issues outside the ticket it was reviewing. The orchestrator turned them into a new ticket and placed it in the right milestone.
• A record you can audit. The Decisions fold holds your answers in your own words. The Assumptions fold holds each choice the crew made on its own, and you keep or change it at the end of each milestone. When a working doc names something that does not work, as one did with a config file that failed on the repo’s Node version, the builder records the substitute as an assumption instead of stopping.

When something else fits

• For a small refactor that does not need a crew, run tares factory session with the idea or the project. It works in your own Claude Code session, still on Tares.
• If your team already tracks work in Linear or GitHub Issues, keep the tickets there. Sessions change them in the tracker and Tares only reads them.
• The software factory is built for solo developers and very small teams, on one machine and your own Claude Code login.

Related