How can I get Claude Code to take on framework migrations on its own, with every change reviewed before it merges?

Tares lets a crew of Claude Code sessions build a framework migration as a list of tickets, each one a pull request the reviewer checks before it merges. You plan the migration once with tares factory spec, and the crew works the tickets and brings you only the questions it cannot settle itself. The shape of your ticket list decides how easy each change is to review.

How it works

The crew is an orchestrator, a reviewer and builders, all Claude Code sessions on your machine. Tares keeps the plan, tickets, reviews and your answers, so a crew that restarts carries on where it stopped.

What one ticket is. A builder takes a ticket, works on its own branch and opens a pull request. In the project walked through on A project, end to end, the builder worked the tickets one at a time and each ticket ended in one pull request. For a migration, think of a ticket as one reviewable change that ends in one pull request.

How the list is grouped. The plan has milestones, each with acceptance checks, and tickets with a working doc each. The orchestrator starts one builder per milestone and repo. In the example project the milestones were tests and CI first, then behavior that must stay as it was, then merged and live. You can cut a migration into milestones the same way.

What the reviewer holds each ticket to. The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request. A builder merges only after the verdict passes and CI is green. If the reviewer asks for changes, the builder makes them and the next round is reviewed again. Two tickets in the example project needed a second round.

When the list changes. The reviewer can find smaller issues outside the ticket in front of it. The orchestrator turns them into a new ticket and places it in the plan. When a builder meets something the plan does not cover, it picks a sensible answer and records it as an assumption. At the end of each milestone, the orchestrator asks whether you keep those assumptions.

Set it up

Follow the order in Get started. Steps marked local apply to a local Tares, and steps marked cloud apply to Tares Cloud.

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. Local: start Tares.

tares up

4. Local: in a second terminal, start the MCP endpoint every crew session shares.

tares mcp --transport streamable-http

5. Cloud: sign in and pick your workspace in the browser.

tares login

6. Give Tares access to GitHub, so it can read the pull request, CI and merge state of every ticket. Use Settings > GitHub for a local Tares, or Connect GitHub on Tares Cloud.
7. Bring up the crew. The first run asks how far it may go: merge on its own after review and green CI, or wait for your yes. It also asks whether a second model checks every commit and how many builders run at once. If you want to approve each migration change yourself, choose to wait for your yes.

tares factory crew up

8. Plan the migration from the repo it changes. Put the migration in the quoted text. The interview asks one question at a time, and a second model challenges the plan. Check that the milestones and tickets match the cut you want, then say yes to hand the project to the crew.

tares factory spec "what you want to build"

9. Answer the crew’s questions in the orchestrator’s session, and follow progress on the Crew page.

tares factory crew attach orchestrator

The project page holds the spec, plan and AGENTS.md. You can edit any of them there, and each ticket’s working doc sits with its ticket. Run tares factory doctor at any point to check what the crew needs.

What you get

• A migration delivered as merged pull requests on main, each reviewed to a fixed bar with the verdict posted on the pull request.
• A project page that shows each ticket with the builder that held it, its pull request and its review rounds, so you can see where a migration stands.
• Blocked tickets that name the tickets they wait for, so you can see the order of the work.
• A record of every choice the crew made on its own, shown as assumptions you keep or change at the end of each milestone.
• Every question the crew asked you and your answer in your own words, in the Decisions fold.
• Several projects at once from one crew. While one project waits for you, the others carry on.

When something else fits

• For a migration small enough to do in one sitting, tares factory session works on a project in your own Claude Code session, still recorded 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 software factory targets solo developers and very small teams. It runs on one machine, on your own Claude Code login and your own GitHub repos.

Related