How do I set up a Tares software factory for Claude Code for a documentation website?

Tares sets up a software factory for Claude Code for your documentation website when you run tares factory spec in the docs repo, or in a folder that holds its repos. The crew runs as Claude Code sessions on your machine and needs Claude Code, gh, git, jq and curl. Start the crew once with tares factory crew up, then plan the docs project and hand it over.

How it works

The software factory for Claude Code is a crew of Claude Code sessions that run in the background on your machine: an orchestrator, a reviewer and builders. Tares holds the plan, the tickets, every review and your answers, so a crew that restarts carries on where it stopped.

Where you run the spec command. tares factory spec runs in the repo the project builds on, or in a folder that holds its repos. For a documentation website, that gives you two cases:

• Your content and your site code live in one repo. Run spec in that repo.
• Your content and your site code live in separate repos. Run spec in the folder that holds them, so one plan covers both.

Builders are started one per milestone and repo, so each repo in the project gets its own builder and its own branch and pull requests.

What the crew needs on the machine.

• Claude Code, signed in, on a plan that allows background sessions. The stations use your Claude Code login, so there is no separate model API key.
• gh, signed in with write access to every repo the crew works in. Builders push and open pull requests with this login.
• git, jq and curl.
• Optionally, the Codex CLI, if you want a second model to check every commit.

The crew itself lives in a folder of its own, ~/factory, so it does not matter which folder you later run spec from.

Language servers. Builders and the reviewer search less when Claude Code can find definitions and references through a language server. tares factory doctor reads each handed-over repo’s languages from its manifests, at the repo root or one folder down. A package.json counts as JavaScript, a tsconfig.json as TypeScript, and a pyproject.toml or requirements.txt as Python. For a missing server, crew up lists what is missing and offers to install it, and it installs only when you say yes.

Set it up

1. Check the prerequisites above. Sign in to GitHub with write access to the docs repos:

   gh auth login

2. Install the CLI and start Tares locally:

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up

3. In a second terminal, start the MCP endpoint every crew session shares. Stations reach Tares only through it, and crew up and spec stop when it does not answer:

   tares mcp --transport streamable-http

   On Tares Cloud, run tares login instead, pick your workspace in the browser and skip this step.

4. Give Tares its own access to GitHub, because it reads the pull request, CI and merge state of every ticket itself. On a local Tares, add a token or App under Settings > GitHub. On Tares Cloud, choose Connect GitHub and pick the docs repos.

5. Bring up the crew. The first run offers to open Claude Code in ~/factory so you can trust the folder, then asks whether the crew merges on its own after review and green CI, whether it releases, how many builders run at once, and what you always allow:

   tares factory crew up

6. Change into the docs repo, or into the folder that holds its repos, and plan the project:

   tares factory spec "what you want to build"

   Claude Code interviews you one question at a time, has a second model attack the plan, and writes the spec, milestones, tickets and an AGENTS.md into a Tares project. Say yes when it asks whether to hand the project to the crew.

7. Answer the crew’s questions in the orchestrator’s session, and run the doctor whenever something looks off:

   tares factory crew attach orchestrator
   tares factory doctor

The full walkthrough is on Get started.

What you get

• One plan for your documentation website, with milestones that have acceptance checks and tickets that each have a working doc.
• Builders that each take a ticket, work on their own branch, open a pull request and merge it once the reviewer passes it and CI is green.
• A reviewer that holds every pull request to a fixed bar and posts its verdict on the pull request.
• One session to talk to. Questions arrive in the orchestrator one at a time, each with a recommendation, and the Crew page in the Tares console shows progress and builders.
• A written record of every assumption the crew made, so you can check it at the end of each milestone.
• A doctor report that tells you which language servers are missing and the command that fixes each problem.

When something else fits

• For a small docs change, run tares factory session "<idea>" to plan and build it in your own Claude Code session, without a crew.
• If you want the tickets in Linear or GitHub Issues instead of Tares, link them from the project’s Tickets page. Tares only reads them.

Related