Where does a builder put its changes when the project changes a Node/TypeScript app?

Tares builders put the changes for a Node/TypeScript app on their own branch and open a pull request, so the change reaches main only through a pull request the reviewer has passed. Each builder takes one ticket, works on its branch and merges only once the reviewer passes the pull request and CI is green. This is how the software factory for Claude Code handles every repo you hand it.

How it works

The software factory for Claude Code runs a crew of Claude Code sessions on your machine. Builders are one part of it, and the same flow applies to your Node/TypeScript repo as to any other.

• One builder per milestone and repo. The orchestrator starts builders for the project, up to the number you allow.
• One ticket, one branch. A builder takes a ticket and works on its own branch. It does not commit to main.
• A pull request opens the change. The builder pushes and opens the pull request with your gh login, so gh needs write access to the repo.
• The reviewer holds the bar. The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request.
• Merge comes last. The builder merges once the reviewer passes the pull request and CI is green. Nothing merges until both conditions hold.
• Tares reads the state. Tares reads the pull request, CI and merge state of every ticket itself, so it needs its own access to the repo through a GitHub token or App locally, or Connect GitHub on Tares Cloud.

If you ask for a releaser, it tags and deploys after the merge. Without one, tickets end at merged on main.

For a repo with a package.json or a tsconfig.json, tares factory doctor also checks whether Claude Code has a language server for JavaScript or TypeScript, so builders and the reviewer can search by symbol. That check is separate from where changes go.

Set it up

Follow these steps in order. Start from the Get started page if you want the full walkthrough.

1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed.

   gh auth login

2. Install the CLI.

   uv tool install tares     # or: brew install glassflow/tap/tares

3. On a local Tares, start Tares, then start the MCP endpoint every crew session shares in a second terminal.

   tares up
   tares mcp --transport streamable-http

4. On Tares Cloud, sign in and pick your workspace in the browser instead. There is no MCP endpoint to start.

   tares login

5. Give Tares access to GitHub: Settings > GitHub for a local Tares, or Connect GitHub on Tares Cloud. Pick the repo that holds your Node/TypeScript app.

6. Bring up the crew. The first run asks how far the crew may go, including whether it merges on its own after review and green CI or waits for your yes.

   tares factory crew up

7. In the repo of your app, plan the project. The crew then builds the tickets into pull requests.

   tares factory spec "what you want to build"

8. Follow the work. The status shows the stations and a line per project, and the projects command lists each project’s builders and repos.

   tares factory crew status
   tares factory projects

What you get

• Every change to your app arrives as a pull request from a builder’s own branch, so you can read the diff, the reviewer’s verdict and the CI result in one place.
• main only receives changes that the reviewer has passed with CI green.
• Several builders can work in parallel on different tickets without sharing a branch.
• Tares keeps the plan, tickets, reviews and your answers, so a crew that restarts carries on from its branches and pull requests.
• You choose how much control you keep. A single project can wait for your yes before every merge, and tares factory crew halt stops merges, pushes and new sessions until crew resume.

When something else fits

• For a small change you would rather drive yourself, run tares factory session to work in your own Claude Code session on the project. If the crew already has the project, its builders push what they have and the session carries on from their branches and pull requests.
• If you want a person to approve every merge, set the crew to wait for your yes instead of merging on its own.

Related