Can a crew of Claude Code sessions handle bug fixes in a documentation website?

Yes, Tares can run a crew of Claude Code sessions that fixes bugs in a documentation website and merges the fixes on main. You plan the fixes as a project, the orchestrator starts one builder per milestone and repo, and each pull request must pass the reviewer and green CI before it merges. The crew runs in the background on your machine, on your own Claude Code login.

How it works

The crew is an orchestrator, a reviewer and builders, plus a releaser only if you ask for one. Tares holds the plan, the tickets, every review and your answers, so a crew that restarts carries on where it stopped.

What changes with the repo is how the work is split and what a pull request has to clear:

• Builder assignment. The orchestrator starts one builder per milestone and repo of a project, up to the number of builders you allow. If your docs site lives in one repo and a milestone covers a set of bug fixes, that milestone gets one builder in that repo. If the site and its content or example code sit in separate repos, each repo gets its own builder for the milestone.
• Tickets. Each builder takes a ticket, works on its own branch and opens a pull request.
• What a pull request must pass. The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request. A builder merges only after the reviewer passes it and CI is green.
• Milestone checks. When you plan the project, /tares:spec writes milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md. Those are the written standard for a bug-fix milestone.
• Optional second model. You can have a second model check every commit, which needs the Codex CLI.

The pull request has to clear whatever CI runs on your repo. Tares reads the pull request, CI and merge state of every ticket itself, so it needs its own GitHub access to the repo.

If you want a human check on one project, it can wait for your yes before every merge, even when the rest of the crew merges on its own.

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 docs repo, plus git, jq and curl.
2. Install the CLI and start Tares locally, or run tares login to use Tares Cloud. The tares package includes the plugin the crew uses.
3. Give Tares access to GitHub so it can read pull requests, CI and merge state. On Tares Cloud, choose Connect GitHub in your workspace settings. Locally, add a token or App under Settings > GitHub. See Get started for both.
4. Bring up the crew. The first run asks whether the crew merges on its own after review and green CI or waits for your yes, whether it releases, whether a second model checks every commit, and how many builders run at once.
5. In your docs repo, plan the bug fixes as a project and say yes when it asks to hand the project to the crew.
6. Answer the crew’s questions in the orchestrator’s session and follow progress on the Crew page.

uv tool install tares     # or: brew install glassflow/tap/tares
tares up                  # console on http://127.0.0.1:8787
tares factory crew up
tares factory spec "what you want to build"
tares factory crew attach orchestrator

Run tares up in its own terminal and leave it running, and run the MCP endpoint described on the get started page in a second one. Then use a third terminal for the crew commands. Run tares factory doctor at any point to check everything the crew needs, and tares factory projects to see each project’s progress, builders and repos.

If you want the bug list to live in an issue tracker, tickets can live in a Linear project or in GitHub Issues instead of Tares. Sessions change them there, and Tares only reads them.

What you get

• Bug-fix tickets built into pull requests on separate branches, one builder per milestone and repo.
• A reviewer verdict on every pull request, held to the same fixed bar.
• Merges on main only after the reviewer passes the change and CI is green.
• A record on Tares of the plan, tickets, reviews, assumptions and your answers, so you can check the crew’s choices at the end of each milestone.
• One place to talk to the crew. Questions from every project reach you in the orchestrator, one at a time, each with a recommendation.
• Several projects at once. While one project waits for you, the others carry on.

When something else fits

• For one small fix, work in your own Claude Code session with tares factory session. It stays on Tares, and it offers the crew if the plan turns out big.
• The software factory is built for solo developers and very small teams on one machine, so a larger team with shared infrastructure is a weaker fit today.
• It needs Claude Code. If your fixes must go through a different coding agent, this crew does not apply.

Related