How do I keep my project tickets in GitHub Issues while a Claude Code crew builds them?

Tares lets a project keep its tickets in a GitHub repo while the Claude Code crew builds them, by linking the repo and an issue label to the project. Tares reads the repo about once a minute and keeps the project’s ticket list in step. Sessions create and change the issues in GitHub with their own tools, and Tares never writes to GitHub. Tickets can live in Tares, Linear or GitHub Issues, and you pick one per project.

How it works

Tickets for a project can live in one of three places: Tares itself, a Linear project, or a GitHub repo. For GitHub Issues, one repo and one issue label pick the issues, and those issues become the project’s tickets.

• What Tares reads. About once a minute, Tares reads every issue in the repo that carries the issue label. Each becomes a ticket named GH-12 (GH- plus the issue number), with its title and status. Sync now on the project’s Tickets page reads at once.
• Status mapping. An open issue is todo. An open issue with the in progress label is in_progress. An issue closed as completed is done. An issue closed as not planned or as a duplicate is canceled.
• Milestones and dependencies. GitHub milestones that the labeled issues belong to appear as milestones in Tares. An issue that is blocked by another makes its ticket depend on that one.
• Who changes what. Sessions create and change issues in GitHub with gh. Tares only reads. The tickets are read-only in Tares, so to change a title, status, milestone or dependency, change the issue in GitHub. Working docs stay yours and you write them in Tares.
• Events. 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.

An issue that loses the label, is deleted or moves to another repo becomes canceled in Tares instead of disappearing, so its working doc stays reachable.

Set it up

1. 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. A GitHub App needs the Issues permission and must be installed on the repo. Tares tries stored credentials one after another until one can read the repo, so a credential you already use for the GitHub connector works.

2. Sign in to gh with the repo scope on the machine that runs the sessions. The sessions use it to create and change issues.

3. Bring up the crew if it is not running yet. The Get started page covers the install and the first-run questions.

   tares factory crew up

4. Plan the project. When you run /tares:spec, say the tickets should live in GitHub Issues and name the repo. Claude creates the issues with gh and links the project for you.

5. Or link an existing repo 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. The label is optional and defaults to tares: followed by the project name. A connected agent can do the same with the MCP tool:

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

6. Check it. 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.

The GitHub Issues connector page has the full mapping and the failure cases.

What you get

• Your tickets stay in the tool where you already read and triage them, and the crew still builds them into pull requests.
• Sessions change the issues with gh, so GitHub holds the current state of every ticket.
• The project’s ticket list in Tares follows GitHub within about a minute, with statuses, milestones and dependencies.
• Every change is an event you can use in triggers.
• A failed sync does not lose work. If a credential is revoked, a repo is no longer visible or GitHub is unreachable, the Tickets page shows why, the tickets stay as they were and nothing is canceled. The next sync picks up once you fix the cause. If GitHub rate limits the sync, Tares waits five minutes before it tries again.
• You can leave at any time. Stop using GitHub on the Tickets page returns the tickets and milestones to Tares with their working docs, and the issues in GitHub stay as they are.

When something else fits

• Keep the tickets in Tares if you want to add and edit tickets and milestones there. If you already use Linear, a project can keep its tickets in a Linear project instead, which works the same way.
• A project that already has tickets of its own, or that keeps them in Linear, cannot be linked to GitHub Issues. A repo and issue label belong to one project.
• GitHub Issues linking covers github.com only, one repo and one label per project, up to 1000 labeled issues and 100 milestones, and no GitHub Projects boards. Group tickets with GitHub milestones.

Related