How many Claude Code sessions does a crew need for docs updates?

Tares runs a docs update with as few as three Claude Code sessions: an orchestrator, a reviewer and one builder. If the docs change is small, you can skip the crew and work in a single session with tares factory session. The crew grows only when the project spans more repos or milestones, because Tares starts one builder per milestone and repo.

How it works

A crew in the software factory for Claude Code is made of these sessions, all running in the background on your machine:

• Orchestrator: hands out work, answers the others and brings you what needs you. It is the only session you talk to.
• Reviewer: reviews every pull request to a fixed bar and posts its verdict on the pull request.
• Builders: one per milestone and repo of a project, started by the orchestrator. Each takes a ticket, works on its own branch, opens a pull request and merges it once the reviewer passes it and CI is green.
• Releaser: only if you ask for one. It tags and deploys. Without it, tickets end at merged on main.

So the count follows the shape of the project, not the type of work. A docs update planned as one milestone in one repo needs the orchestrator, the reviewer and one builder, which is three sessions. A plan with two repos, or with several milestones, gets more builders, up to the number you allow when tares factory crew up asks how many builders run at once. Add one more session only if you ask for a releaser.

Tares holds the plan, the tickets, every review and your answers, so the sessions can stop and restart and the crew carries on where it stopped.

If you do not need a crew at all, tares factory session opens one Claude Code session bound to the project. That session plans a small project and builds it right there, so one session can be enough.

Set it up

Pick the path that matches the size of your docs update.

Path 1: the crew (three sessions for a one-repo docs update)

1. Check that Claude Code is signed in on a plan that allows background sessions, 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.
3. Point it at Tares. For a local Tares, run tares up, then in a second terminal start the MCP endpoint every crew session shares with tares mcp --transport streamable-http. For Tares Cloud, run tares login and pick your workspace in the browser. There is no MCP endpoint to start.
4. Give Tares access to GitHub: Settings > GitHub on a local Tares, or Connect GitHub on Tares Cloud.
5. Bring up the crew. The first run asks whether the crew merges on its own after review and green CI, whether it releases, and how many builders run at once. Keep the builder limit in line with the number of repos and milestones in your docs plan.
6. Plan the docs update in the repo it touches. Tares interviews you, writes the spec, milestones and tickets, and asks whether to hand the project to the crew. Say yes and the orchestrator picks it up.

uv tool install tares     # or: brew install glassflow/tap/tares
tares up                  # local Tares only
tares mcp --transport streamable-http     # local Tares only, in a second terminal
tares login               # Tares Cloud only, instead of the two lines above
tares factory crew up
tares factory spec "what you want to build"

Path 2: one session for a small update

Skip crew up and open one Claude Code session on the project:

tares factory session "<idea>"      # plan a small project and build it right there

If the plan turns out big, the session offers the full spec and the hand-over to the crew instead. For the full walkthrough, see Get started.

What you get

• A small, predictable crew. One repo and one milestone means one builder, with the orchestrator and reviewer around it.
• Review on every pull request. The reviewer holds each change to a fixed bar, and nothing merges until it passes and CI is green.
• One place to talk. You answer questions in the orchestrator’s session, one at a time, with a recommendation each.
• Progress in view. The Crew page of the Tares console shows each project’s builders and the pull requests waiting for review.
• A cheaper path for tiny work. A single session on Tares keeps your shared AGENTS.md and memory, and its record lands on the project.
• Room to grow. The same crew serves many projects at once, so a docs update can run next to other work while the orchestrator starts builders for each project.

When something else fits

• Use tares factory session when the docs change is small and you are happy to drive it in one session. You skip the orchestrator and reviewer.
• Use the crew when you want every pull request reviewed by a separate session, or when the update spans several repos or milestones and you want builders working in parallel.

Related