Should the crew merge pull requests for small features 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 small feature once the reviewer approves and CI is green. At L3-review, every merge waits for your yes. The reviewer checks every pull request at either setting.
How it works
The software factory for Claude Code is a crew of Claude Code sessions that run in the background on your machine. Each role has one job in the path from ticket to merge:
- The orchestrator hands out work and starts builders, 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.
Merging is your setting, and it decides what happens after the verdict:
| Setting | What happens to a merge |
|---|---|
L4-ship | The builder merges once the reviewer approves and CI is green. |
L3-review | Every merge waits for your yes. |
So L4-ship hands the merge to the crew and keeps the reviewer’s verdict and green CI as the gate. L3-review keeps you as the last gate on every pull request, small features included.
The setting is about merging. Other decisions that are yours reach you either way. Questions wait on the desk until you answer them. When the plan does not answer a smaller question, the crew records an assumption and carries on, and the orchestrator confirms the assumptions with you once per milestone. Releasing is off unless you ask for it, so without a releaser the crew stops when work is merged to main.
Set it up
-
Make sure Claude Code is signed in,
ghis signed in with write access to the repos the crew works in, and git, jq and curl are installed. -
Install Tares, sign in on Tares Cloud, bring up the crew and plan a project:
uv tool install tares # or: brew install glassflow/tap/tares tares login tares factory crew up tares factory spec "what you want to build"To run Tares on your own machine instead, replace
tares loginwithtares upand start the MCP endpoint the sessions share. Build a software factory with Claude Code has the local and Tares Cloud setup, what you need on your machine and the commands to watch the crew. -
Decide your merge setting. Start with
L3-reviewif you want to see how the crew writes and reviews code before it lands anything on its own. Move toL4-shipwhen the reviewer’s verdicts and your CI match what you would accept yourself. -
When something needs your yes, attach to the orchestrator and answer there. It brings you one question at a time, with a recommendation:
tares factory crew attach orchestrator -
Read Run autonomous, self-running Claude Code sessions to see how the crew keeps working while you are away. A watch brings back any session that stops, and the orchestrator checks for work every 20 minutes.
What you get
- A clear choice for small features. At
L4-shipthey go from ticket to main without you. AtL3-revieweach one waits for your yes. - Review at both settings. Every pull request gets the reviewer’s verdict against a fixed bar, whatever you pick.
- A merge gate you can name. At
L4-shipthe gate is an approved review and green CI. AtL3-reviewthe gate is you. - Work that continues while you are away. Reviewed pull requests merge on their own at
L4-ship, and the next ticket can start. AtL3-reviewthe crew can have the pull request ready and waiting when you return. - Your own decisions stay yours. Questions on the desk wait for your answer, and assumptions are confirmed with you once per milestone.
- No surprise releases. Releasing is off unless you ask for it, so merged work stays on main until you decide otherwise.
A practical rule for which changes deserve your yes: if you would not be comfortable with a change landing on main on an approved review and green CI alone, keep L3-review for your work. If the reviewer’s bar and your CI already cover what you care about for small features, L4-ship saves you the round trip.
When something else fits
- Pick
L3-reviewwhen CI is thin, when you are new to the crew, or when you want to read every change before it lands on main. - Pick
L4-shipwhen you want the crew to keep moving while you are away and you trust the reviewer’s verdict together with your CI. - If you only want to be asked about plan-level decisions, use the desk and the per-milestone assumption check. That does not replace a merge approval.
Related
- Run autonomous, self-running Claude Code sessions
- Should the crew merge pull requests for bug fixes on its own or wait for my yes?
- Should the crew merge dependency upgrade pull requests on its own or wait for my yes?
- How do I limit what a Claude Code crew can touch while it does small features in a Node/TypeScript app?
Still stuck? Get help