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

Tares keeps your project tickets by default: when you plan with tares factory spec, the plan, milestones and tickets are written into a Tares project, and the Claude Code crew builds them from there. You do not link Linear or GitHub Issues. Tickets can also live in Linear or GitHub Issues, and Tares then reads them about once a minute.

How it works

Tares is the backbone of the software factory for Claude Code. It holds the plan, the tickets and their stages, every review, the assumptions the crew made, the questions it asked you and your answers. The sessions come and go, but the record stays on Tares, so a crew that restarts carries on where it stopped.

When the tickets live in Tares itself, planning creates them there:

• /tares:spec (or tares factory spec) interviews you one question at a time, has a second model attack the plan, and writes it into a Tares project.
• The project holds the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md.
• The orchestrator hands out work. Builders, one per milestone and repo, each take a ticket, work on their own branch and open a pull request.
• The reviewer reviews every pull request to a fixed bar. A builder merges once the reviewer passes it and CI is green.
• Tares reads the pull request, CI and merge state of every ticket itself, so it needs its own access to your GitHub repos.

Tickets have three possible homes:

For Linear and GitHub Issues, the sessions change the tickets with their own tools, and Tares only reads the result to keep the project’s ticket list in step.

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 the crew works in, plus git, jq and curl.

2. Install the CLI and start Tares:

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

3. In a second terminal, start the MCP endpoint every crew session shares. Stations reach Tares only through this endpoint:

   tares mcp --transport streamable-http     # http://127.0.0.1:8788/mcp

4. Give Tares access to GitHub so it can read pull request, CI and merge state. On Tares Cloud, choose Connect GitHub in your workspace settings. Locally, add a GitHub token or App under Settings > GitHub.

5. Bring up the crew. The first run asks how far the crew may go, such as whether it merges on its own after review and green CI or waits for your yes:

   tares factory crew up

6. In the repo the project builds on, plan the project. Because you do not name Linear or GitHub Issues, the tickets are written into Tares:

   tares factory spec "what you want to build"

7. When the plan ends by asking whether to hand the project to the crew, say yes. The orchestrator picks it up.

8. Answer the crew’s questions in the orchestrator’s session, and follow progress on the Crew page of the console:

   tares factory crew attach orchestrator

Run tares factory doctor at any point to check everything the crew needs. The full walkthrough is in Build a software factory with Claude Code.

To move tickets to Linear or GitHub Issues instead, use the Tickets page of the project. Click Use a Linear project after connecting Linear in Settings > Linear, or Use GitHub Issues after adding a GitHub credential in Settings > GitHub. For GitHub Issues, sign in to gh with the repo scope on the machine that runs the sessions.

What you get

• One place for the plan, tickets, stages, reviews, assumptions and your answers, with nothing else to connect.
• A crew that restarts and carries on where it stopped, because the record stays on Tares.
• Tickets that end at merged on main, or at a release if you asked for a releaser.
• One crew working on many projects at once. Questions from every project reach you in the orchestrator’s session, and the Crew page shows each project’s progress and builders.
• A record of every choice the crew made on its own, so you can check it at the end of each milestone instead of during every step.

When something else fits

Keep tickets in Tares itself when you want the shortest path from plan to merged pull requests.

Choose Linear when your tickets already live in a Linear project and you want to keep them there. Sessions change the tickets in Linear, and Tares reads them about once a minute. Read access to Linear is enough, since Tares never writes to it.

Choose GitHub Issues when you want the tickets next to the code. Say so when you run /tares:spec and name the repo, and Claude creates the issues with gh and links them. Tares reads them about once a minute and never writes to GitHub.

If the project is small, you do not need a crew. Run tares factory session to plan it and build it in your own Claude Code session, still on Tares.

Related