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

Tares keeps the tickets itself, so you plan the upgrades with tares factory spec and the crew builds them into reviewed, merged pull requests. The plan holds milestones with acceptance checks and tickets that each carry a working doc. Builders take the tickets one at a time, the reviewer holds every pull request to a fixed bar, and a builder merges once the review passes and CI is green.

How it works

Tickets live in Tares by default. You do not link Linear or GitHub Issues unless you want to.

• The plan. tares factory spec opens Claude Code with /tares:spec. It interviews you one question at a time and has a second model attack the plan. It then writes a Tares project: the spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md.
• The working doc. Each ticket’s working doc sits with the ticket. It is what the builder reads for that ticket, so put the package, the target version and the files to touch in it.
• Order. A ticket is in one of five states: to do, in progress, in review, merged or blocked. A blocked ticket names the tickets it waits for, so a dependency between upgrades is visible in the Tickets fold. A builder works through its tickets one at a time, and the orchestrator can add a ticket to a milestone ahead of others when review turns up more work.
• Review and merge. For each ticket the builder makes a branch, does the work and opens a pull request. The reviewer posts its verdict on the pull request. Once the verdict passes and CI is green, the builder merges. If you chose to approve every merge, the crew waits for your yes first.
• The record. Tares holds the plan, the tickets, every review round, the assumptions the crew made and your answers. If a session restarts, the crew carries on from that record.

The project end to end page shows a real build with this shape: three milestones, each with acceptance checks, and eight merged pull requests.

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 (gh auth login), and that git, jq and curl are installed.

2. Install the CLI and start Tares locally. On Tares Cloud, run tares login instead and skip the MCP step.

   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. A local crew reaches Tares only through it.

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

4. Give Tares access to GitHub, under Settings > GitHub on a local Tares or with Connect GitHub on Tares Cloud. Tares reads the pull request, CI and merge state of every ticket with it. The Get started page has the full setup.

5. Bring up the crew. The first run asks how far it may go: merge on its own after review and green CI, or wait for your yes, and how many builders run at once.

   tares factory crew up

6. In the repo, plan the upgrades. Name them in the idea, then use the interview to say what must hold afterwards, for example that the test suite and CI pass. Ask for a working doc on each ticket that names the package and the target version.

   tares factory spec "upgrade our dependencies one package at a time, keeping tests and CI green"

7. When the session asks whether to hand the project to the crew, say yes. The orchestrator picks it up and starts a builder.

8. Answer questions in the orchestrator’s session.

   tares factory crew attach orchestrator

9. Run tares factory doctor if a station misbehaves. It prints the command that fixes each problem.

What you get

• Tickets that carry their own checks. Each milestone holds its acceptance checks, and each ticket holds a working doc, all on Tares.
• One pull request per ticket. The Tickets fold shows each ticket with the builder that held it, its pull request and its review rounds. In the example project, most tickets passed on the first round and two took a second.
• A reviewed upgrade path. Nothing merges until the reviewer passes it and CI is green.
• Decisions you can check. When the plan does not cover something, the crew picks a sensible answer and writes it down as an assumption. In the example, a working doc named a config file that failed to load on the repo’s Node version, so the builder used a working alternative and recorded it. The orchestrator brings the assumptions to you at the end of each milestone.
• Few interruptions. You answer the questions the crew cannot settle itself, in the orchestrator’s session. The Crew page in the console (http://127.0.0.1:8787/crew locally) shows progress, the question waiting for you and the pull requests in the review queue.
• A clear finish. After the last milestone the orchestrator asks whether the project is finished, and Tares marks it Done with your words.

When something else fits

• If your team already tracks work in Linear or GitHub Issues, keep the tickets there. Tares reads them about once a minute and never writes to them, and the Get started page has the steps.
• For one small upgrade, tares factory session "<idea>" plans it and builds it in your own Claude Code session, without a crew.

Related