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

Tares lets the software factory for Claude Code build test coverage straight from GitHub Issues. You label the issues for one repo, link them to a Tares project, and the crew works them into merged pull requests. Each ticket carries a working doc and sits in a milestone with acceptance checks, and the crew picks tickets up in order. Tares reads the issues about once a minute, and sessions create and change them with gh.

How it works

Tares links one GitHub repo and one issue label to a project. Every open or closed issue with that label becomes a ticket named GH-12, GH-13 and so on, in issue number order.

• Status follows the issue. An open issue is todo, an open issue with the in progress label is in_progress, one closed as completed is done, and one closed as not planned or as a duplicate is canceled.
• Order follows dependencies. An issue that is blocked by another makes its ticket depend on that one, so the crew takes the blocker first.
• Milestones come from GitHub. The milestones your labeled issues belong to become the project’s milestones. The goal starts as the GitHub milestone’s description, and you write the acceptance checks in Tares.
• The working doc stays yours. Tickets are read-only in Tares, but each ticket’s working doc is written in Tares as for any ticket.

The crew itself is an orchestrator, a reviewer and builders. A builder takes one ticket at a time, works on its own branch, opens a pull request, and merges once the reviewer passes it and CI is green. Tares never writes to GitHub.

For a test milestone, the project walkthrough shows the shape: a milestone named “tests and CI on the branch”, with a test framework, unit tests for the logic and a CI check on every pull request as its checks.

Set it up

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. Install the CLI and start Tares as described in Get started. On a local Tares, start the MCP endpoint in a second terminal:

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

   On Tares Cloud, run tares login and pick your workspace instead. There is no MCP endpoint to start.

2. 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. Then sign in to gh with the repo scope on the machine that runs the sessions:

   gh auth login --scopes repo

3. Bring up the crew:

   tares factory crew up

4. Plan the project in the repo, and say the tickets should live in GitHub Issues and name the repo. Ask for the coverage work as its own milestone, with the checks that define done:

   tares factory spec "raise test coverage of the checkout module"

   /tares:spec interviews you, writes the milestones with acceptance checks and a working doc for each ticket, creates the issues with gh, and links them. It ends by asking whether to hand the project to the crew. Say yes.

5. To use issues that already exist, give them one issue label and group them with GitHub milestones. Then, on the project’s Tickets page, click Use GitHub Issues, pick the repo, check the label and click Link. A connected agent can do the same:

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

   The label defaults to tares: followed by the project name. Then write each ticket’s working doc and each milestone’s checks in Tares, and mark blockers in GitHub so the order is right.

6. Answer the crew’s questions in the orchestrator’s session with tares factory crew attach orchestrator.

What you get

• Test tickets that live where your team already tracks work. You change titles, milestones and blockers in GitHub, and Tares follows within about a minute. Sync now on the Tickets page reads at once.
• A crew that works the tickets in order, with each pull request reviewed to a fixed bar before it merges.
• A project page that records each ticket with its builder, pull request and review rounds. It also records every question the crew asked you and every choice it made on its own.
• Events on the github_issues source for each change (ticket_created, ticket_renamed, ticket_status, ticket_removed), so triggers and agents can react to them.
• Safe failure. If a sync fails, the tickets stay as they were and nothing is canceled. An issue that loses its label becomes canceled and keeps its working doc.

The GitHub Issues connector page covers the sync details and what to do when something goes wrong.

When something else fits

• If you have no tracker to keep in step, let Tares hold the tickets itself. /tares:spec creates them there.
• If your repo is on GitHub Enterprise Server, GitHub Issues cannot be linked, because only github.com is supported. A project is also limited to one repo and one issue label, up to 1000 labeled issues and 100 milestones.
• For a single small change, tares factory session works on it in your own Claude Code session without a crew.

Related