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

Tares lets you keep framework migration tickets in GitHub Issues while a crew of Claude Code sessions builds them into pull requests. You label the issues, link the repo to a Tares project, and bring up the crew. Tares reads the issues about once a minute and never writes to GitHub. Sessions create and change the issues with gh.

How it works

• One repo and one label pick the tickets. Every issue that carries the issue label becomes a ticket named GH-<number>, with its title and status. The label defaults to tares: followed by the project name.
• Status follows the issue. An open issue is todo, an open issue with the in progress label is in_progress, an issue closed as completed is done, and one closed as not planned or as a duplicate is canceled.
• Milestones group the migration. GitHub milestones that the labeled issues belong to become Tares milestones. You write each milestone’s goal and acceptance checks in Tares. Add or reorder milestones in GitHub, because Tares cannot add them.
• Dependencies carry over. An issue that is blocked by another makes its ticket depend on that one, and a ticket that waits on others shows as blocked on them in the project’s Tickets fold.
• Working docs stay yours. Tickets are read-only in Tares, but each ticket’s working doc is written in Tares, as for any ticket.
• The crew builds them. The orchestrator starts builders 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. See A project, end to end for a real run.

Set it up

1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed. Sign in to gh with the repo scope on the machine that runs the sessions:

   gh auth login --scopes repo

2. Install the CLI and start Tares locally:

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up                  # console on http://127.0.0.1:8787

3. In a second terminal, start the MCP endpoint every crew session shares:

   tares mcp --transport streamable-http     # http://127.0.0.1:8788/mcp

   On Tares Cloud you run tares login instead and there is no MCP endpoint to start.

4. Add a GitHub credential in Settings > GitHub that can read the repo’s issues. A fine-grained token needs the repo with Issues: read, a classic token needs the repo scope, and a GitHub App needs the Issues permission and an installation on the repo. On Tares Cloud, choose Connect GitHub.

5. Bring up the crew:

   tares factory crew up

6. Plan the migration project in the repo it builds on:

   tares factory spec "what you want to build"

   When the interview starts, say the tickets should live in GitHub Issues and name the repo. Claude creates one issue per ticket with gh, applies the label, and links the project. Put each migration step in its own issue and group them with GitHub milestones.

7. To link an existing repo yourself, click Use GitHub Issues on the project’s Tickets page and pick the repo and label. A connected agent can do the same with the MCP tool:

   link_github_issues(repo="acme/shop", issue_label="tares:shop")

8. In Tares, write each milestone’s goal and checks, and add a working doc to each ticket. Answer the crew’s questions with tares factory crew attach orchestrator.

A project that already has tickets of its own, or that keeps them in Linear, cannot be linked. See Get started for the full setup.

What you get

• Tickets that stay in your tracker, where your team already reads and edits them. Closing an issue as completed moves the ticket to done within about a minute.
• Acceptance checks on each milestone and a working doc on each ticket, both kept in Tares next to the project.
• Dependencies from blocked-by links, so a ticket that waits on another shows as blocked.
• Pull requests that the reviewer holds to a fixed bar, and that merge once the reviewer passes them and CI is green.
• Events on the github_issues source for each change (ticket_created, ticket_renamed, ticket_status, ticket_removed), so triggers and agents can react to them.
• A record that survives changes in GitHub. An issue that loses the label, is deleted or moves repos becomes canceled in Tares, so its working doc stays reachable.

The GitHub Issues connector page covers the sync in full. If a sync fails, the Tickets page shows why, the tickets stay as they were, and nothing is canceled.

When something else fits

• If you want to change titles, statuses or milestones from Tares, use Tares tickets, or click Stop using GitHub on the Tickets page to return the tickets and their working docs to Tares. The issues in GitHub stay as they are.
• The link covers one repo and one issue label per project, github.com only, up to 1000 labeled issues and 100 milestones, and no GitHub Projects boards. If your migration spans more than that, split it across projects or keep the tickets in Tares or Linear.
• For a small migration, tares factory session builds it in your own Claude Code session without the crew.

Related