How do I get Claude Code to ship framework migrations from tickets that live in Tares itself?

Tares holds the migration tickets itself: you plan them with tares factory spec, and the crew builds each one into a pull request merged on main. The plan has milestones with acceptance checks and tickets with a working doc each. Builders take the tickets one at a time, the reviewer checks every pull request, and you answer only the questions the crew cannot settle itself.

How it works

Tares is the backbone of the crew. It holds the plan, the tickets and their stages, every review, the assumptions the crew made and your answers. Tickets live in Tares by default, so there is nothing extra to connect.

• Planning. tares factory spec opens Claude Code with /tares:spec. It interviews you one question at a time, has a second model attack the plan, and writes a Tares project: the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md.
• Hand-over. The spec session ends by asking whether to hand the project to the crew. Say yes and the orchestrator picks it up and starts a builder for each milestone and repo.
• Building. A builder works through its tickets one at a time. For each, it makes a branch, does the work and opens a pull request. The reviewer posts a verdict on every pull request, and the builder merges once the verdict passes and CI is green.
• Order. Each ticket shows its state: to do, in progress, in review, merged or blocked. A blocked ticket names the tickets it waits for, so you can see what stands in its way on the project page.
• Surprises. When the crew meets something the plan did not cover, it picks a sensible answer, writes it down as an assumption and carries on. In the end-to-end example, the working doc named a config file that failed to load on the repo’s Node version, so the builder used another file and recorded it. The orchestrator brings the assumptions to you at the end of each milestone.

The project end to end page follows one such project from spec to eight merged pull requests.

Set it up

1. Check that Claude Code is signed in, 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 and start Tares locally.

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

3. In a second terminal, start the MCP endpoint every crew session shares. On Tares Cloud, run tares login instead and pick your workspace in the browser.

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.

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

tares factory crew up

6. Plan the migration from the repo it applies to. Say what you are migrating and what each step must prove. During the interview, ask for acceptance checks on every milestone and a working doc on every ticket, with the commands and files the builder should use.

tares factory spec "migrate the app to the next major version of its framework, one milestone per step"

7. Answer yes when asked to hand the project to the crew. Then open the orchestrator to answer its questions.

tares factory crew attach orchestrator

Follow progress on the Crew page of the console, and run tares factory doctor if a station misbehaves. The Get started page has the full setup.

What you get

• Each migration step becomes a ticket with its milestone’s acceptance checks and its own working doc, all kept on Tares.
• Every ticket ends as a reviewed pull request, merged after a passing verdict and green CI.
• A project page that shows each ticket’s state, its builder, its pull request and its review rounds, with blocked tickets naming what they wait for.
• A Decisions fold with every question the crew asked and your answer in your own words.
• An Assumptions fold with every choice the crew made alone, so you review them once per milestone instead of at every step.
• New tickets when the reviewer finds smaller issues. In the example, the orchestrator added one inside a milestone, ahead of the integration tests.
• A crew that restarts without losing its place, because the record stays on Tares.

When something else fits

• If your tickets already live in Linear or GitHub Issues, keep them there. Sessions change them in that tracker and Tares only reads them.
• For a small migration that does not need a crew, run tares factory session to plan and build it in your own Claude Code session, still recorded on Tares.
• If you want to approve each merge yourself, say so at crew up. A project can wait for your yes before every merge.

Related