Where do I see progress on bug fixes when the tickets live in GitHub Issues?

Tares shows bug fix progress on the project page, in the Tickets fold, while the tickets stay in GitHub Issues. Each ticket appears with its status, the builder that held it, its pull request and its review rounds. The sessions update the issues in GitHub with their own tools, and Tares only reads them.

How it works

Your bug fixes stay as GitHub issues. One repo and one issue label pick which issues belong to the project, and Tares turns those issues into the project’s tickets, named GH-12 for issue 12.

• Sessions write, Tares reads. The sessions create and change the issues in GitHub with gh. Tares never writes to GitHub Issues, so the tickets are read-only in Tares.
• Sync about once a minute. Tares reads the repo on that schedule. Sync now on the Tickets page reads at once.
• Status comes from 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.
• Every change is an event. Each change becomes an event on the github_issues source: ticket_created, ticket_renamed, ticket_status or ticket_removed. Triggers and agents can react to them like any other event.
• Dependencies and milestones follow GitHub. An issue that is blocked by another makes its ticket depend on that one, and the GitHub milestones of the labeled issues become the project’s milestones.

The ticket’s pull request and review rounds come from the factory’s own work on the project. The builder opens a pull request for each ticket, the reviewer posts a verdict, and the Tickets fold records both next to the ticket. See A project, end to end for a full walkthrough.

Set it up

Start from the software factory setup on Get started. The steps below are for a local Tares, in the order the factory expects. On Tares Cloud you sign in with tares login instead of running tares up and tares mcp.

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.

2. Install the CLI, start Tares and start the MCP endpoint every crew session shares (the last command goes in a second terminal). Then bring up the crew.

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up
   tares mcp --transport streamable-http
   tares factory crew up

3. Add a GitHub credential in Settings > GitHub. It must be able to 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.

4. Plan the project and say 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. Or link an existing project yourself. On 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:

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

   The issue label is optional. It defaults to tares: followed by the project name, and Tares creates the github_issues source the first time you link a project.

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

See the GitHub Issues connector for the full setup and limits.

What you get

• One page for the build. Each project you hand to the crew has a page with four steps, Spec, Build, Review and Done, and a progress bar with one segment per ticket.
• Bug fix detail per ticket. The Tickets fold lists milestones with their acceptance checks, and each ticket with its state (to do, in progress, in review, merged or blocked), the builder that held it, its pull request and its review rounds. A blocked ticket names the tickets it waits for.
• Open pull requests at a glance. The GitHub fold lists the repos the project changes, where each is checked out, and their open and merged pull requests.
• The crew’s state. The Crew page, at http://127.0.0.1:8787/crew locally, shows what each station is doing, which questions wait for you, and the pull requests in the review queue.
• Your tracker stays the source of truth. If an issue loses its label, is deleted or moves to another repo, its ticket becomes canceled rather than disappearing, so its working doc stays reachable. If a sync fails, the Tickets page shows why and the tickets stay as they were.

When something else fits

• If you want the tickets to live in Tares, or to edit titles, statuses and milestones there, keep them in Tares or 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.
• GitHub Issues linking covers one repo and one issue label per project, github.com only, with no GitHub Projects boards, and up to 1000 labeled issues. If your tickets are in Linear, the Linear connector works the same way.

Related