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

Tares keeps a project’s tickets itself, so you plan the bug fixes with tares factory spec and a crew of Claude Code sessions builds them into merged pull requests. Each ticket has a working doc, and each milestone has acceptance checks. The builder works through the tickets one at a time.

How it works

When you plan a project, Tares stores the whole plan: the spec, the plan, an AGENTS.md for the project, milestones with acceptance checks, and tickets with a working doc each. The tickets live on the project’s Tickets page in the Tares console, and you do not need Linear or GitHub Issues for this.

Once you hand the project over, the crew takes it from there:

• The orchestrator starts a builder for each milestone and repo.
• The builder works through the tickets one at a time. For each ticket it makes a branch, does the work and opens a pull request.
• The reviewer reviews every pull request and posts its verdict on it.
• When the verdict passes and CI is green, the builder merges.

Each ticket shows its state: to do, in progress, in review, merged or blocked. A blocked ticket names the tickets it waits for. If a pull request needs changes, the reviewer asks for them, the builder makes them and the next review round decides.

The plan can grow while the crew works. When the reviewer finds smaller issues outside the ticket it is reviewing, the orchestrator turns them into a new ticket and places it in the milestone. In the example project in A project, end to end, the crew took a pull request with a few bugs in how it paid shifts to eight merged pull requests in about three hours.

Set it up

1. Check what you need: Claude Code signed in on a plan that allows background sessions, gh signed in with write access to the repos, plus git, jq and curl. Get started lists them.

2. Install the CLI and start Tares. Then run tares login if you use Tares Cloud, and start the MCP endpoint in a second terminal as Get started describes. Give Tares access to GitHub too, so it can read pull request, CI and merge state for each ticket.

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up                  # console on http://127.0.0.1:8787

3. Bring up the crew. The first run asks how far the crew may go: merge on its own after review and green CI, or wait for your yes. It also asks about a releaser, a second model checking commits, and how many builders run at once.

   tares factory crew up

4. In the repo with the bugs, run the spec command and describe the bug fixes in your own words. Claude Code opens with /tares:spec, interviews you one question at a time and has a second model challenge the plan.

   tares factory spec

5. Shape the tickets while you answer. Group the fixes into milestones and state the acceptance checks for each milestone as behavior you can verify. The example project used “payout history stays as it was” for the shift payout fixes. Put what a builder needs into each ticket’s working doc, such as the files involved and the commands to run.

6. When the interview ends, say yes to handing the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.

7. Answer the crew’s questions with tares factory crew attach, which opens the orchestrator’s session. Follow progress on the Crew page and the project page. If you want a change in direction, talk to the orchestrator.

What you get

• Bug-fix tickets kept in Tares, each with a working doc, grouped under milestones that carry acceptance checks.
• One pull request per ticket, reviewed to a fixed bar by the reviewer, and merged only after the verdict passes and CI is green.
• A project page that records each ticket’s builder, pull request and review rounds, so you see the stage of every fix.
• Assumptions. When the crew meets something the plan does not cover, it picks a sensible answer, writes it down and carries on. In the example, the working doc named a config file that failed to load on the repo’s Node version, so the builder used another and recorded the choice. The orchestrator brings the assumptions to you at the end of each milestone, so you check them in one place.
• A record that survives restarts. Tares keeps the plan, tickets, reviews and your answers, so a crew that stops carries on where it left off.

When something else fits

• If your team already tracks bugs in Linear or GitHub Issues, keep the tickets there. Sessions change them in that tracker and Tares reads them about once a minute. Tares never writes to them.
• For one small fix that does not need a crew, run tares factory session to work on it in your own Claude Code session, still bound to a Tares project.
• If you want to check each step yourself, set the crew to wait for your yes before every merge.

Related