How can I get Claude Code to take on docs updates on its own, with every change reviewed before it merges?

Tares runs a crew of Claude Code sessions that turns a planned docs project into reviewed pull requests. You plan it with tares factory spec, and the crew works the tickets one at a time. A reviewer holds every pull request to a fixed bar, and nothing merges until it passes and CI is green. The kind of work you describe in the spec decides what the ticket list looks like.

How it works

The software factory for Claude Code is an orchestrator, a reviewer and builders, all Claude Code sessions on your machine. Tares keeps the plan, the tickets, the reviews and your answers, so a restarted crew carries on where it stopped.

The spec session turns your description of the work into a Tares project:

• Milestones, each with acceptance checks.
• Tickets, each with a working doc of its own.
• An AGENTS.md for the project, which every session that builds it reads.

What one ticket is. A builder takes a ticket, works on its own branch, opens a pull request and merges it once the reviewer passes it and CI is green. One ticket is one unit of work that goes through that whole path: a branch, a pull request, a review and a merge. The builder works through a milestone’s tickets one at a time.

How big a ticket is. The ticket list follows from your description of the work and the plan the spec session writes. In the project followed on A project, end to end, the plan had three milestones and eight tickets. Another project had 20 tickets over three milestones. For docs updates, describe the pages or areas you want changed. The plan then splits them into tickets, grouped under milestones whose acceptance checks say what done means.

What the reviewer holds it to. The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request. Some tickets pass on the first round. Others take a second round, where the reviewer asks for changes, the builder makes them and the next round passes. If the reviewer finds smaller issues outside the ticket, the orchestrator turns them into a new ticket and places it in the plan.

When the plan is off. If a working doc names something that does not fit, the builder picks the sensible answer, writes it down as an assumption and carries on. In the example project, a working doc named a config file that failed to load, so the builder used another file and recorded it. You review those assumptions at the end of each milestone.

Set it up

1. Check that you have Claude Code signed in on a plan that allows background sessions, gh signed in with write access to the docs repo, plus git, jq and curl.
2. Install the CLI and start Tares. In a second terminal, start the MCP endpoint every crew session shares. In a third, run tares login if you use Tares Cloud.
3. Give Tares access to GitHub so it can read the pull request, CI and merge state of every ticket. On Tares Cloud, choose Connect GitHub in your workspace settings. Locally, add a token or App under Settings > GitHub. See GitHub.
4. Bring up the crew. The first run asks how far it may go. Choose whether it merges on its own after review and green CI, or waits for your yes, and how many builders run at once.
5. In the docs repo, plan the work. The spec session interviews you one question at a time and has a second model challenge the plan. Say what docs you want updated, and answer the questions it asks. End by saying yes to handing the project to the crew.
6. Open the orchestrator to answer the crew’s questions, and follow progress on the Crew page.

tares factory crew up
tares factory spec "what you want to build"
tares factory crew attach orchestrator

Run tares factory doctor at any point to check everything the crew needs. The full walkthrough is in Get started.

What you get

• Every change reviewed. The reviewer posts a verdict on each pull request, and a merge waits for a pass and green CI.
• A ticket list you can read. The project page shows milestones with their acceptance checks, and each ticket with its builder, pull request and review rounds.
• A record of choices. Every question the crew asked and every assumption it made is kept, with your answers in your own words.
• Control over merging. The crew can merge on its own after review, or a single project can wait for your yes before every merge.
• Few interruptions. You answer the questions only you can, and check the crew’s own choices at the end of each milestone.

When something else fits

• For a one-page fix, work in your own Claude Code session with tares factory session. It plans a small project and builds it there, and no crew is needed.
• If your tickets already live in Linear or GitHub Issues, keep them there. The crew’s sessions change them with their own tools, and Tares reads them.

Related