How do I get Claude Code to ship small features from tickets in GitHub Issues?

Tares lets you keep a project’s tickets in GitHub Issues and have a crew of Claude Code sessions build them into pull requests merged on main. You link one repo and one issue label to a project, write each ticket’s acceptance checks and working doc, and the crew works through the tickets in order. See Get started for the full factory setup.

How it works

• Issues become tickets. Tares reads your repo about once a minute. Every issue carrying the project’s issue label becomes a ticket named GH-<number>, in issue number order. The label defaults to tares:<project name>.
• Status follows the issue. An open issue is todo, an open issue with the in progress label is in_progress, a closed issue is done, and one closed as not planned or duplicate is canceled.
• Order comes from GitHub. An issue that is blocked by another makes its ticket depend on that one, so the crew takes the blocker first. Group related small features with GitHub milestones.
• Checks and docs live in Tares. A milestone’s goal starts as the GitHub milestone’s description, and you can write your own goal and the acceptance checks in Tares. Each ticket’s working doc stays yours, written in Tares.
• The crew builds. A builder takes one ticket at a time, works on its own branch and opens a pull request. The reviewer reviews it, and the builder merges once the reviewer passes it and CI is green.
• Tares only reads. Sessions create and change issues with gh. Tickets are read-only in Tares, so to change a title, status, milestone or dependency, change the issue in GitHub.

The GitHub Issues connector page has the full mapping and the events each change records.

Set it up

1. Check your tools. Claude Code must be signed in. gh must be signed in with write access to the repos the crew works in, and with the repo scope so sessions can create issues. git, jq and curl must be installed.

   gh auth login

2. Install the CLI and start Tares locally.

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up

3. Start the MCP endpoint in a second terminal. Every crew session shares it.

   tares mcp --transport streamable-http

   On Tares Cloud, run tares login instead and pick your workspace in the browser. 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, and a classic token needs the repo scope. A GitHub App needs the Issues permission and must be installed on the repo.

5. Bring up the crew.

   tares factory crew up

6. Plan the project. Run this in the repo, and when /tares:spec interviews you, 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. Keep each issue to one small feature, and use blocked-by links where one must land before another. To link an existing repo yourself, click Use GitHub Issues on the project’s Tickets page, or ask a connected agent to call the MCP tool:

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

7. Write the checks and the working docs. In Tares, add the acceptance checks to each milestone and a working doc to each ticket. Say what done looks like and which files or commands matter.

8. Hand the project to the crew. When the spec ends, say yes. Then run tares factory crew attach orchestrator to answer its questions.

To verify, close an issue in GitHub. Within a minute its ticket moves to done, and the source’s Recent events shows the change.

What you get

• Small features go from issue to merged pull request without you driving each prompt. The crew builds tickets in order and respects blocked-by links.
• Every pull request is reviewed to a fixed bar, and nothing merges until it passes and CI is green.
• Your tracker stays the source of truth for what to build. Close, rename or reorder issues in GitHub and the tickets follow within a minute.
• Tares keeps the record, so a crew that restarts carries on where it stopped. An issue that loses its label becomes canceled, so its working doc stays reachable.
• The crew asks you only what it cannot decide itself. It writes down every choice it made on its own, so you can check them at the end of each milestone.

A project, end to end follows a real project from spec to eight merged pull requests.

When something else fits

• If you want to plan tickets inside Tares and edit them there, skip the link. Tares tickets are editable, while GitHub-linked tickets are read-only in Tares.
• GitHub Issues fits one repo and one label per project, on github.com only, with up to 1000 labeled issues. GitHub Projects boards and GitHub Enterprise Server are not supported, so use GitHub milestones for grouping.

Related