Should the crew merge pull requests for bug fixes on its own or wait for my yes?

Tares lets you choose. At L4-ship, a builder in the software factory for Claude Code merges a bug fix once the reviewer approves and CI is green. At L3-review, every merge waits for your yes. Merging is your setting, so you decide how much of the bug-fix flow runs without you.

How it works

The software factory for Claude Code is a crew of Claude Code sessions that run in the background on your machine. Three roles touch a bug-fix pull request:

• The orchestrator hands out work and starts builders itself, one per milestone and repo of a project. It is also the session you talk to.
• A builder takes its tickets, opens pull requests and merges its own once they pass.
• The reviewer reviews every pull request to a fixed bar and posts the verdict.

Every pull request gets the reviewer’s verdict whichever merge setting you pick. The setting decides what happens after the verdict:

• L4-ship: a builder merges once the reviewer approves and CI is green. You are not asked.
• L3-review: every merge waits for your yes. The builder opens the pull request and the reviewer posts the verdict, then the merge waits for you.

Questions that need you wait on the desk until you answer them. The orchestrator brings them to you one at a time, with a recommendation. When the plan does not answer a smaller question, the crew records an assumption and carries on. The orchestrator then confirms the assumptions with you once per milestone.

For the full picture of how the sessions keep running and pick up work, see Run autonomous, self-running Claude Code sessions.

Set it up

1. Install Tares, sign in and bring up the crew. Then plan the project, which Tares keeps as tickets, each with the repo it changes.

uv tool install tares     # or: brew install glassflow/tap/tares
tares login
tares factory crew up
tares factory spec "what you want to build"

2. To run Tares on your own machine instead of Tares Cloud, replace tares login with tares up and start the MCP endpoint the sessions share.
3. Decide which merge setting fits your bug fixes. Choose L4-ship if reviewer approval and green CI are enough for a fix to land. Choose L3-review if you want to say yes to each merge yourself.
4. If you run L3-review, attach to the orchestrator to answer what is waiting for you:

tares factory crew attach orchestrator

5. Leave releasing as it is unless you want it. Releasing is off unless you ask for it, so without a releaser the crew stops when work is merged to main.

What you get

• With L4-ship: bug fixes move from ticket to merged pull request while you are away. The crew works in the background and a watch brings back any session that stops. The orchestrator checks for work every 20 minutes, so a merged pull request can unblock the next ticket without you.
• With L3-review: you see the reviewer’s verdict and give a yes before each merge. Nothing lands on main without you.
• Either way: every pull request gets the same fixed-bar review. Your answers, the plan, the tickets and the reviews stay in Tares. If you run tares factory crew down and later tares factory crew up, fresh sessions carry on from them.
• No surprise releases: the crew stops at merged-to-main unless you have asked for a releaser.

When something else fits

Pick L3-review when you want to look at every change before it lands, for example while you are still learning how the crew’s pull requests look, or when a merge to main is something you want to approve yourself. The cost is that merges wait until you attach to the orchestrator and answer.

Pick L4-ship when the reviewer’s approval and green CI are the bar you want for a merge, and you would rather the crew keep going while you are away.

The merge setting covers merging only. Decisions that are yours, such as the questions on the desk and the assumptions confirmed once per milestone, still come to you at either setting.

Related