How do I require green CI before Claude Code merges changes to a Node/TypeScript app?

In the Tares software factory for Claude Code, a builder merges a pull request only after the reviewer passes it and CI is green. That gate is always on for every repo the crew works in, including your Node/TypeScript app. The merge setting you choose on the first run only decides whether the crew also waits for your yes. Tares reads the pull request, CI and merge state through its own GitHub access.

How it works

The crew is an orchestrator, a reviewer and builders, all Claude Code sessions running in the background on your machine. Here is how a change for your Node/TypeScript app reaches main:

• A builder takes a ticket, works on its own branch and opens a pull request with your gh login.
• The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request.
• The builder merges once the reviewer passes the pull request and CI is green. Both conditions apply to every merge.
• Tares reads the pull request, CI and merge state of every ticket itself. It needs its own access to your repos for this, separate from the gh login the builders use.

Two things are easy to mix up:

• The gate. Review plus green CI is how builders merge. You do not switch it on.
• The merge setting. On the first tares factory crew up, the crew asks whether it merges on its own after review and green CI (the recommended choice) or waits for your yes as well. Choosing to wait adds your approval on top of the gate. It never removes the gate.

A single project can also wait for your yes before every merge, even when the rest of the crew merges on its own.

GitHub access is how Tares sees the state of the pull request and its CI. It is not a switch that turns gating on or off. Give Tares access so it can read that state for each ticket.

Set it up

1. Check what you need. Claude Code must be signed in on a plan that allows background sessions. gh must be signed in with write access to the repos the crew works in, and you need git, jq and curl.

2. Install the CLI and start Tares. Tares can run next to the crew, with the console at http://127.0.0.1:8787.

uv tool install tares     # or: brew install glassflow/tap/tares
tares up                  # console on http://127.0.0.1:8787

3. In a second terminal, start the MCP endpoint that every crew session shares.

tares mcp --transport streamable-http     # http://127.0.0.1:8788/mcp

4. If you use Tares Cloud instead of a local Tares, sign in and pick your workspace in the browser.

tares login

5. Give Tares its own GitHub access to the repo that holds your Node/TypeScript app:

   • On Tares Cloud, choose Connect GitHub in your workspace settings and pick the repos.
   • On a local Tares, add a GitHub token or App under Settings > GitHub.

6. Bring up the crew and answer the first-run questions. Pick whether the crew merges on its own after review and green CI, or waits for your yes. Your answers are kept on Tares.

tares factory crew up

7. Plan the project from the repo your app lives in. The plan becomes milestones and tickets, and the crew builds them into pull requests.

tares factory spec "what you want to build"

8. Run the check at any point to confirm everything the crew needs is in place.

tares factory doctor

The Get started page covers the full quickstart, including how to answer the crew’s questions with tares factory crew attach orchestrator.

What you get

• Nothing merges on main until the reviewer has passed the pull request and CI is green.
• A reviewer that holds every pull request to the same fixed bar and posts its verdict where you can see it.
• A merge state that Tares tracks per ticket, because it reads the pull request, CI and merge state itself.
• Your choice of autonomy: let the crew merge after review and green CI, or add your own yes before merges.
• A stop button. tares factory crew halt stops merges, pushes and new sessions until crew resume.
• A record on Tares of the plan, tickets, reviews and your answers, so a crew that restarts carries on where it stopped.

You spend your time on the plan and on the few questions the crew cannot answer itself, not on watching terminals.

When something else fits

• If you want to approve each merge yourself, choose the wait-for-your-yes option on the first run, or set a single project to wait. The review and CI gate still applies.
• If the work is small and you want to stay in the loop, use tares factory session to build in your own Claude Code session on Tares instead of running the whole crew.

Related