Where do I see progress on framework migrations when the tickets live in GitHub Issues?

Tares shows migration progress on the project page, where each ticket from your GitHub Issues appears with its pull request and review rounds. The issues stay in GitHub and your sessions update them with gh, while Tares reads the repo about once a minute. The page also has a progress bar with one segment per ticket, and the Crew page shows who holds what.

How it works

Tares keeps your tickets in GitHub and only reads them. The sessions of the software factory for Claude Code create and change the issues with gh. Tares never writes to GitHub.

• One repo and one issue label pick the issues. Every issue that carries the label becomes a ticket named GH-<number>, in issue number order.
• Tares reads the repo about once a minute. Sync now on the Tickets page reads at once.
• The issue sets the ticket status. An open issue is todo, an open issue with the in progress label is in_progress, an issue closed as completed is done, and an issue closed as not planned or as a duplicate is canceled.
• GitHub milestones that the labeled issues belong to become milestones in Tares. An issue that is blocked by another makes its ticket depend on that one.
• Every change becomes an event on the github_issues source, keyed by the ticket name. The event types are ticket_created, ticket_renamed, ticket_status and ticket_removed.

The project page is the record of the build. Across the top it shows four steps, Spec, Build, Review and Done, and a progress bar with one segment per ticket. The Tickets fold lists milestones with their acceptance checks, and each ticket with the builder that held it, its pull request and its review rounds. The GitHub fold lists the repos the project changes and their open and merged pull requests. For a worked example, see A project, end to end. The GitHub Issues connector page covers the sync in full.

Set it up

1. Add a GitHub credential in Settings > GitHub. It must 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 must be installed on the repo.

2. Make sure the sessions that create issues can use gh with the repo scope.

   gh auth login

3. Start Tares and bring up the crew. On a local Tares, start the MCP endpoint in a second terminal before the crew. Follow Get started for the full prerequisites.

   tares up
   tares mcp --transport streamable-http
   tares factory crew up

4. Plan the migration with a spec and say in the planning session that the tickets should live in GitHub Issues. Claude creates them with gh and links the project.

   tares factory spec "what you want to build"

5. If you would rather link by hand, open the project’s Tickets page, click Use GitHub Issues, pick or type the repo as owner/name, check the issue label and click Link. A connected agent can call the MCP tool instead. The label is optional and defaults to tares:<project name>.

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

6. When you answer yes at the end of the spec, the project is handed to the crew. Open the project page and the Tickets fold to follow the work. The Crew page is at http://127.0.0.1:8787/crew on a local Tares.

7. Check the link. The Tickets page shows “Tickets live in GitHub” with the repo, the issue label and the time of the last sync. Close an issue in GitHub and within a minute its ticket moves to done, and the source’s Recent events shows the change.

What you get

• One page that shows the state of the whole migration: the step it is in, how many tickets are done, and each ticket with its builder, pull request and review rounds.
• Ticket states from the project page: to do, in progress, in review, merged or blocked. A blocked ticket names the tickets it waits for.
• A Decisions fold with every question the crew asked you and your answer, and an Assumptions fold with every choice the crew made on its own.
• The Standup report on the Crew page, which lists what is done, started, in review, blocked and waiting on you for each project, with pull request links.
• Tickets that stay in your tracker. Your team keeps using GitHub for issues, labels and milestones, and Tares shows the progress next to the pull requests.
• A sync that fails safely. If a credential is revoked or GitHub is unreachable, the Tickets page shows why, the tickets stay as they were and nothing is canceled. An issue that loses its label becomes canceled in Tares rather than disappearing, so its working doc stays reachable.

When something else fits

• Tickets are read-only in Tares. To change a title, status, milestone or dependency, change the issue in GitHub. If you want to edit tickets in Tares, use Stop using GitHub on the Tickets page. The tickets and milestones return to Tares with their working docs, and the issues in GitHub stay as they are.
• The link is limited to one repo and one issue label per project, github.com only, with up to 1000 labeled issues and 100 milestones. It does not read GitHub Projects boards, so group tickets with GitHub milestones.
• A project that already has tickets of its own, or keeps them in Linear, cannot be linked to GitHub Issues.

Related