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

Tares keeps the tickets for your docs updates itself, so you plan the work once and the crew of Claude Code sessions ships each ticket as a merged pull request. Each ticket carries its milestone’s acceptance checks and a working doc of its own. Builders take the tickets one at a time, the reviewer holds every pull request to a fixed bar, and the builder merges once the reviewer passes it and CI is green.

How it works

Tickets live in Tares by default. You only move them to Linear or GitHub Issues if you choose to. When you plan a project, Tares writes down:

• A spec, a plan and an AGENTS.md for the project.
• Milestones, each with acceptance checks.
• Tickets, each with a working doc.

For a docs project, the working doc is where a ticket says which pages to change and what the change must contain. The acceptance checks say when the work counts as done. Every session that builds the project reads the same record, so a builder that restarts picks up where it stopped.

The crew runs as Claude Code sessions on your machine:

• Orchestrator: hands out work and brings you the questions that need you. It is the only session you talk to.
• Builders: one per milestone and repo. A builder works the tickets one at a time. For each ticket it makes a branch, does the work and opens a pull request.
• Reviewer: reviews every pull request and posts its verdict.

A ticket shows one state: to do, in progress, in review, merged or blocked. A blocked ticket names the tickets it waits for, so the order of your tickets is visible on the project page. If the reviewer finds smaller issues outside the ticket it is reviewing, the orchestrator can add a ticket for them and place it where it belongs. A project, end to end follows one project through this flow.

Set it up

1. Check that Claude Code is signed in, gh is signed in with write access to the repos the crew works in, and git, jq and curl are installed.
2. Install the CLI and start Tares locally, then start the MCP endpoint every crew session shares in a second terminal. On Tares Cloud, run tares login instead and skip the MCP step.
3. Give Tares access to GitHub, in Settings > GitHub for a local Tares or Connect GitHub on Tares Cloud. Tares reads each ticket’s pull request, CI and merge state with it.
4. 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.
5. In the repo that holds your docs, plan the project. Describe the docs updates as concrete pieces of work, and ask for acceptance checks that a reviewer can verify, such as which pages change and what each must say. Do not ask for Linear or GitHub Issues, so the tickets stay in Tares.

uv tool install tares     # or: brew install glassflow/tap/tares
tares up                  # console on http://127.0.0.1:8787
tares mcp --transport streamable-http     # second terminal, http://127.0.0.1:8788/mcp
tares factory crew up
tares factory spec "what you want to build"

6. Answer the interview. Claude Code asks one question at a time, a second model challenges the plan, and the result goes into a Tares project. At the end it asks whether to hand the project to the crew. Say yes and the orchestrator picks it up.
7. Open the project page and read the Tickets fold. Check that each ticket has the acceptance checks you want and a working doc that names its pages. You can edit the docs from All docs in the Docs fold.
8. Follow progress on the Crew page at http://127.0.0.1:8787/crew. Use tares factory crew attach to open the orchestrator and answer its questions. Run tares factory doctor if a station misbehaves.

The full walkthrough is on Get started.

What you get

• Docs updates arrive as pull requests, one per ticket, each reviewed and merged on main only after the reviewer passes it and CI is green.
• The project page records the whole build: tickets with their builder, pull request and review rounds, plus the spec, plan and docs the crew read.
• When the crew meets something the plan did not cover, it picks a sensible answer, writes it down as an assumption and carries on. For example, a working doc can name a file that does not fit the repo, and the builder uses a fitting one and records the choice. At the end of each milestone you see these assumptions in one question and decide which to keep.
• Your answers stay in your own words in the Decisions fold, so you can check what you agreed to.
• You spend your time on the plan and a few questions, not on watching terminals.

When something else fits

• If your team already tracks work in Linear or GitHub Issues, keep the tickets there. Sessions change them in that tracker and Tares reads them, and Tares never writes back.
• For one small change, run tares factory session to work in your own Claude Code session on Tares instead of bringing up a crew.

Related