Where does a builder put its changes when the project changes a documentation website?

Tares builders put their changes on their own branch and open a pull request, so a documentation website change reaches the default branch only through a pull request the reviewer has passed. The builder merges it once the reviewer passes it and CI is green. If you want a say, you can make a project wait for your yes before every merge.

How it works

A documentation website is handled like any other repo in a project. The software factory for Claude Code gives each repo of a project its own builder, one per milestone and repo, started by the orchestrator. For a documentation website, that builder does the following:

• Takes a ticket from the project.
• Works on its own branch, never directly on the default branch.
• Pushes the branch and opens a pull request, using your gh login.
• Waits for the reviewer.

The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request. Nothing merges until it passes. After the reviewer passes the change and CI is green, the builder merges it.

Tares reads the pull request, CI and merge state of every ticket itself, so it needs its own access to the repos. On Tares Cloud you choose Connect GitHub in your workspace settings. On a local Tares you add a GitHub token or App under Settings > GitHub.

The record stays on Tares: the plan, the tickets and their stages, every review and your answers. If a station restarts, the crew carries on where it stopped. The Get started page covers the whole crew.

Set it up

1. Check that Claude Code is signed in and that git, jq and curl are installed. Sign in to gh with write access to the repo that holds the documentation website, because builders push and open pull requests with that login.

   gh auth login

2. Install the CLI.

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

3. On a local Tares, start Tares, then start the MCP endpoint every crew session shares in a second terminal. On Tares Cloud, run tares login instead and pick your workspace in the browser.

   tares up
   tares mcp --transport streamable-http

4. Give Tares access to GitHub, so it can read the pull request, CI and merge state of each ticket.

5. Bring up the crew. The first run asks how far the crew may go, including whether it merges on its own after review and green CI or waits for your yes.

   tares factory crew up

6. In the documentation website repo, or in a folder that holds its repos, plan the project. Say what you want to change on the site.

   tares factory spec "what you want to build"

7. Follow the work. Run tares factory projects to see each project’s progress, builders and repos. The Crew page of the console shows the pull requests waiting for review, at http://127.0.0.1:8787/crew on a local Tares.

   tares factory projects

Run tares factory doctor at any point to check everything the crew needs.

What you get

• Every documentation website change arrives as a pull request on a branch of its own, so you can read the diff before it lands.
• The reviewer holds each pull request to the same fixed bar and posts its verdict on the pull request.
• Merges happen only after the reviewer passes the change and CI is green.
• You choose how much freedom the crew has. It can merge on its own, or a single project can wait for your yes before every merge while the rest of the crew merges on its own.
• The tickets, reviews and your answers stay on Tares, so you can check what the crew did at the end of each milestone.
• Without a releaser, tickets end at merged on the default branch. A releaser, which tags and deploys, exists only if you ask for one.

When something else fits

• If the change is small and you want to drive it yourself, run tares factory session to work on the project in your own Claude Code session, still on Tares.
• If you want to approve every merge, set the crew to wait for your yes, either for the whole crew or for one project.

Related