Skip to Content
Tares

How does the crew’s work on docs updates reach main?

Tares sends docs updates to main through a pull request, the same way as any other work from the software factory for Claude Code. A builder takes the ticket, works on its own branch and opens a pull request. The reviewer posts its verdict on that pull request, and the builder merges once the reviewer passes it and CI is green.

How it works

A docs update is a ticket like any other, and it follows the crew’s normal path. Nothing in this path is specific to docs.

  • Plan. The ticket comes from the plan you wrote with tares factory spec. Tickets can also live in Linear or GitHub Issues, and Tares reads them from there.
  • Hand-out. The orchestrator starts a builder for each milestone and repo of the project. The orchestrator hands out the work and is the only session you talk to.
  • Branch and pull request. The builder takes a ticket and works on its own branch. It pushes and opens the pull request with your gh login, so main never receives a direct push from the builder’s working copy.
  • Review. The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request.
  • Merge. The builder merges its own pull request once the reviewer passes it and CI is green.
  • Record. Tares reads the pull request, CI and merge state of every ticket itself. It keeps the plan, the tickets, every review and your answers, so a crew that restarts carries on where it stopped.

If you did not ask for a releaser, tickets end at merged on main. With a releaser, it handles tagging and deploying after that. For more on how the crew fits together, see Get started.

Set it up

  1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed.
  2. Install the CLI. On a local Tares, run tares up, then start the MCP endpoint every crew session shares with tares mcp --transport streamable-http in a second terminal. On Tares Cloud, sign in with tares login instead.
  3. Give Tares access to GitHub, so it can read each pull request, its CI and its merge state. On Tares Cloud choose Connect GitHub. On a local Tares add a token or App under Settings > GitHub.
  4. Bring up the crew. The first run asks whether the crew merges on its own after review and green CI (recommended) or waits for your yes.
  5. Plan the docs work as a project, with the docs changes as tickets, and say yes when asked to hand it to the crew.
tares factory crew up
tares factory spec "what you want to build"
  1. Answer the crew’s questions in the orchestrator’s session and watch progress on the Crew page, which lists the pull requests waiting for review.
tares factory crew attach orchestrator

What you get

  • Every docs update lands on main through a reviewed pull request, not a direct push.
  • The reviewer’s verdict sits on the pull request itself, next to the change it judges.
  • Merging needs two things together: a pass from the reviewer and green CI.
  • You are pulled in only for decisions that are really yours. You can also require your yes before every merge on a single project, even when the rest of the crew merges on its own.
  • You can stop merges at any time with tares factory crew halt. It stops merges, pushes and new sessions until crew resume.
  • tares factory crew status shows the stations, the questions for you and a line per project. tares factory projects lists each project’s progress, builders and repos.

When something else fits

  • For a very small docs change you would rather make yourself, work in your own Claude Code session with tares factory session, still on Tares.
  • If you want to approve each merge yourself, choose the setting where the crew waits for your yes.

Still stuck? Get help

Last updated on
Quickstart