Skip to Content

How does the crew’s work on internal refactors reach main?

Tares gets a refactor to main through a pull request: a builder works on its own branch, the reviewer posts a verdict, and the builder merges once it passes and CI is green. A refactor is a ticket like any other, so it follows the same path as every ticket in a project. Tares keeps the record of the ticket, the review and the merge, so a crew that restarts carries on where it stopped.

How it works

The crew is a set of Claude Code sessions running in the background on your machine. Three roles take part in getting a change to main:

  • Orchestrator. It hands out work and starts builders, one per milestone and repo of a project.
  • Builder. It takes a ticket, works on its own branch and opens a pull request. Once the reviewer passes the pull request and CI is green, the builder merges it.
  • Reviewer. It reviews every pull request to a fixed bar and posts its verdict on the pull request.

So a refactor planned as a ticket moves through these steps:

  1. The orchestrator gives the ticket to a builder.
  2. The builder pushes its branch and opens a pull request with your gh login.
  3. The reviewer reviews the pull request and posts its verdict on it.
  4. When the reviewer passes it and CI is green, the builder merges it.
  5. The ticket ends at merged on main, unless you asked for a releaser, which tags and deploys.

Tares reads the pull request, CI and merge state of every ticket itself, which is why it needs its own access to your repos. It also holds the plan, the tickets and their stages, every review and the assumptions the crew made.

You set how far the crew may go the first time you run tares factory crew up. You choose whether it merges on its own after review and green CI (the recommended setting) or waits for your yes. A single project can also wait for your yes before every merge while the rest of the crew merges on its own.

Set it up

Follow these steps in order. They apply to a refactor as to any other work you hand the crew.

  1. Check that Claude Code is signed in, gh is signed in with write access to the repos the crew works in, and git, jq and curl are installed.

    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. There is no MCP endpoint to start.

    tares up
    tares mcp --transport streamable-http

  4. Give Tares access to GitHub: add a token or App under Settings > GitHub for a local Tares, or choose Connect GitHub on Tares Cloud. The builders push with your gh login, and Tares uses this access to read pull request, CI and merge state.

  5. Bring up the crew. On the first run, answer the questions about merging after review and green CI, releasing, and how many builders run at once.

    tares factory crew up

  6. Plan the refactor as a project. Describe it in your own words, and the spec writes milestones, acceptance checks and tickets into Tares.

    tares factory spec "what you want to build"

  7. When the spec ends, say yes to handing the project to the crew. The orchestrator picks it up and starts a builder for each milestone and repo.

To follow the work, run tares factory crew status for the stations and a line per project, or tares factory projects for each project’s progress, builders and repos. The Crew page in the console also lists the pull requests waiting for review. The full walkthrough is in Get started.

What you get

  • Every change reaches main through a pull request, and nothing merges until the reviewer passes it and CI is green.
  • Each builder works on its own branch, so builders on different tickets do not share one.
  • The reviewer’s verdict sits on the pull request itself, next to the change it judges.
  • The builder that opened the pull request merges it, so you do not have to merge by hand unless you chose to approve merges.
  • Tares keeps the tickets, reviews, assumptions and your answers, so you can check what the crew decided at the end of each milestone instead of during every step.
  • You are pulled in only for questions the crew cannot answer itself. They reach you one at a time in the orchestrator’s session.
  • You can stop merges at any time with tares factory crew halt, which also stops pushes and new sessions until you run tares factory crew resume.

When something else fits

  • If you want to look at every change before it lands, set the crew, or a single project, to wait for your yes before each merge.
  • If a refactor is small enough that you want to drive it yourself, work on the project in your own Claude Code session with tares factory session. If the crew already has the project, the session can take it over when you say yes. The builders push what they have and write their progress, and the session continues from their branches and pull requests.
  • If you need a change tagged and deployed, ask for a releaser. Without one, tickets end at merged on main.

Still stuck? Get help

Last updated on