Should the crew merge pull requests for dependency upgrades on its own or wait for my yes?

Tares lets you decide: at L4-ship a builder merges its own pull request once the reviewer approves and CI is green, and at L3-review every merge waits for your yes. Dependency upgrades follow whichever merge setting you choose. Pick L4-ship if reviewer approval and green CI are enough for you, and L3-review if you want to see the upgrade before it lands.

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 every pull request:

• 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 has two values:

• 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 reviewer checks every pull request in both modes. The setting only decides whether your yes is also required before the merge. Releasing is separate and off unless you ask for it. Without a releaser, the crew stops when work is merged to main.

When a decision is yours, the orchestrator brings it to you one question at a time and with a recommendation. Questions wait on the desk until you answer them, so nothing is merged or decided behind your back at L3-review.

Set it up

1. Install Tares and bring up the crew. On Tares Cloud, sign in once with tares login. To run Tares on your own machine, replace tares login with tares up.

uv tool install tares     # or: brew install glassflow/tap/tares
tares login
tares factory crew up

2. Plan the project with Claude. Tares keeps the plan as tickets, each with the repo it changes, and the orchestrator starts builders for them. You do not assign anything.

tares factory spec "what you want to build"

3. Choose your merge setting. Use this test: if you would not merge the change on a reviewer’s approval and green CI alone, choose L3-review. Some examples of changes that often deserve your yes:

   • A major version bump of a framework or runtime that the whole repo depends on.
   • An upgrade that touches authentication, payments or data storage.
   • An upgrade your CI barely exercises, so green CI tells you little.

   Routine upgrades that your tests cover well are the natural fit for L4-ship.

4. At L3-review, answer the waiting merges by attaching to the orchestrator:

tares factory crew attach orchestrator

5. Keep an eye on the crew. The orchestrator checks for work every 20 minutes, and a watch brings back any session that stops. tares factory crew down stops every station, and Tares keeps the projects, tickets and answers for the next tares factory crew up.

The full flow is described in Run autonomous, self-running Claude Code sessions. Get started has the Local and Tares Cloud setup and the commands to watch the crew.

What you get

• Hands-off upgrades at L4-ship. A builder merges its own pull request after the reviewer approves and CI is green, so upgrades keep moving while you are away.
• A checkpoint at L3-review. Every merge waits for your yes, and the orchestrator asks one question at a time with a recommendation.
• A review on every pull request. The reviewer applies a fixed bar and posts the verdict in both modes.
• Continuity. Tares keeps the plan, the tickets, the reviews and your answers, so a revived session carries on from where the last one stopped.
• Fewer interruptions on small questions. When the plan does not answer a smaller question, the crew records an assumption and carries on. The orchestrator confirms the assumptions with you once per milestone.

When something else fits

• Choose L3-review when an upgrade could change behavior in ways your tests do not show, or when you simply want to read every change before it reaches main.
• Choose L4-ship when you trust the reviewer’s bar and your CI to catch problems, and your yes would only slow the work down.
• Merging is the only part of this decision. If you also want releases, you have to ask for them, because the crew stops at merged-to-main by default.

Related