How does the crew’s work on small features reach main?

Tares gets small features onto main through pull requests: a builder takes the ticket, works on its own branch, opens a pull request, and merges it once the reviewer passes it and CI is green. The reviewer posts its verdict on the pull request itself. Without a releaser, the ticket ends at merged on main.

How it works

Every change travels the same path, from ticket to merged pull request, through the crew of Claude Code sessions that Tares runs on your machine.

• Planning. tares factory spec writes the plan into a Tares project: the spec, milestones with acceptance checks, and tickets with a working doc each. The orchestrator picks the project up when you hand it over.
• Building. The orchestrator starts a builder for each milestone and repo. The builder takes a ticket and works on its own branch, so work on main stays untouched until the merge.
• Pull request. The builder pushes and opens the pull request with your gh login.
• Review. The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request.
• Merge. The builder merges once the reviewer passes the pull request and CI is green. Nothing merges until it passes.
• Tracking. Tares reads the pull request, CI and merge state of every ticket itself, so the ticket’s stage follows what happens on GitHub. The plan, the tickets, every review and your answers stay on Tares, so a crew that restarts carries on where it stopped.

The reviewer and builders are separate sessions, so the session that wrote a change is not the one that passes it.

Set it up

Set up the crew once, then hand it work. For a local Tares the steps run in this order.

1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in (gh auth login), and that git, jq and curl are installed.
2. Install the CLI, start Tares and start the MCP endpoint that every crew session shares. On Tares Cloud, run tares login instead and skip the MCP endpoint.
3. Give Tares its own access to GitHub so it can read pull request, CI and merge state. On a local Tares, add a token or App under Settings > GitHub. On Tares Cloud, choose Connect GitHub in your workspace settings and pick the repos.
4. Bring up the crew. On the first run it asks how far the crew may go. Choose that it merges on its own after review and green CI (the recommended option), or that it waits for your yes.
5. Plan the feature in the repo it builds on, and answer the orchestrator’s questions as they come.

tares up
tares mcp --transport streamable-http   # in a second terminal
tares factory crew up
tares factory spec "what you want to build"
tares factory crew attach orchestrator

The spec command ends by asking whether to hand the project to the crew. Say yes and the orchestrator hands the tickets to builders. The Get started page covers each step in full.

To see where a feature stands, run tares factory crew status for the stations and a line per project, or open the Crew page of the Tares console, which lists the pull requests waiting for review. Run tares factory doctor if a station misbehaves.

What you get

• Each change arrives on main as a reviewed pull request, not as a direct push.
• Every pull request carries the reviewer’s verdict, held to a fixed bar.
• A merge needs both a pass from the reviewer and green CI.
• You are pulled in only for decisions that are yours. Choices the crew makes on its own are written down, so you can check them at the end of a milestone.
• You can keep a hand on the merge. A single project can wait for your yes before every merge, even when the rest of the crew merges on its own.
• You can stop merging at any time. tares factory crew halt with a reason stops merges, pushes and new sessions until you run tares factory crew resume.
• The record of tickets, reviews and answers lives on Tares, so a restart does not lose the thread.

When something else fits

• If you want to build a small project yourself in one Claude Code session, run tares factory session with your idea. The session is bound to the project on Tares, and if the crew already has the project, you can take it over from the crew’s branches and pull requests.
• If you want more than a merge on main, such as a tag and a deploy, ask for a releaser. Without one, tickets end at merged on main.

Related