Skip to Content
Tares

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

Tares lets you keep a project’s tickets in GitHub Issues, so the software factory for Claude Code builds each bug fix from an issue into a pull request. You write each bug as an issue with the project’s label, group the issues in a GitHub milestone, and write the acceptance checks and a working doc for each ticket in Tares. The crew then works the tickets and merges what the reviewer passes. Tares only reads GitHub, and sessions create and change the issues with gh.

How it works

  • Issues become tickets. One repo and one issue label pick the issues. Each labeled issue becomes a ticket named GH-<number>, in issue number order, with its title and status. Tares reads the repo about once a minute.
  • 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. An issue closed as not planned or as a duplicate is canceled.
  • Milestones group the fixes. The GitHub milestones that your labeled issues belong to become milestones in Tares. The goal starts as the GitHub milestone’s description, and you can write your own goal and the acceptance checks in Tares.
  • Dependencies set the order. An issue that is blocked by another makes its ticket depend on that one.
  • The crew builds them. The orchestrator starts builders, one per milestone and repo. Each builder takes a ticket, works on its own branch and opens a pull request. The reviewer reviews every pull request, and the builder merges once the reviewer passes it and CI is green.
  • Working docs stay yours. The tickets are read-only in Tares, but a ticket’s working doc is written in Tares as for any ticket.

See A project, end to end for a real project that went from spec to merged pull requests this way.

Set it up

  1. 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, and a classic token needs the repo scope. Also sign in to gh with the repo scope on the machine that runs the sessions.

  2. Bring up the crew if it is not running yet. See Get started for the full setup.

    tares factory crew up
  3. Plan the project. Run the spec command in the repo and say the tickets should live in GitHub Issues and name the repo.

    tares factory spec "what you want to build"

    Claude creates the issues with gh and links the project. It also writes the milestones with acceptance checks and a working doc for each ticket.

  4. Or link an existing repo yourself. On the project’s Tickets page, click Use GitHub Issues, pick the repo, 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 label is optional and defaults to tares:<project name>.

  5. Write each bug as an issue. Give it the project’s label and put it in a GitHub milestone. If one fix must land before another, mark the second issue as blocked by the first.

  6. Fill in the checks and the working docs in Tares. Write the milestone’s acceptance checks, and for each ticket a working doc that says what to fix and how to know it is fixed.

  7. Answer the crew’s questions. Open the orchestrator’s session:

    tares factory crew attach orchestrator

A project that already has tickets of its own, or that keeps them in Linear, cannot be linked. A repo and issue label belong to one project.

What you get

  • Bug fixes that arrive as pull requests, each reviewed to a fixed bar before it merges.
  • A ticket list that stays in step with GitHub. Close an issue as completed and, within a minute, its ticket moves to done. The source’s Recent events shows the change.
  • Events for every change: ticket_created, ticket_renamed, ticket_status and ticket_removed. Triggers and agents can react to them like any other event.
  • A record on the project page: milestones with their acceptance checks, each ticket with its pull request and review rounds, and the questions the crew asked you.
  • No lost history. An issue that loses the label, is deleted or moves to another repo becomes canceled in Tares, so its working doc stays reachable.

If a sync fails, the Tickets page shows why and the tickets stay as they were. Fix the cause and the next sync picks up. Run tares factory doctor to check what the crew needs.

When something else fits

  • If you want to add or edit tickets and milestones inside Tares, keep them in Tares. Stop using GitHub on the Tickets page returns them with their working docs, and the issues in GitHub stay as they are. See the GitHub Issues connector.
  • GitHub Enterprise Server and GitHub Projects boards are not supported, and a project takes one repo and one issue label, up to 1000 labeled issues. For a small fix, tares factory session works on it in your own Claude Code session.

Still stuck? Get help

Last updated on