What should the reviewer check when a builder opens a pull request for small features in a Node/TypeScript app?

Tares has the reviewer check every pull request a builder opens against the acceptance checks of the ticket and post a verdict. The builder merges once the verdict passes and CI is green. In a Node/TypeScript app you also confirm that tests and CI cover the change, that tooling fits the repo’s Node version, that existing data is untouched, and that the pull request is documented.

How it works

Each ticket sits under a milestone, and each milestone carries acceptance checks that the spec session wrote. The builder works one ticket at a time: it makes a branch, does the work and opens a pull request. The reviewer reviews every pull request and posts its verdict.

• Pass and green CI: the builder merges.
• Changes requested: the builder makes them and a second review round follows. In the worked project, two tickets took a second round and then passed.
• Findings outside the ticket: the reviewer may spot smaller issues beyond the ticket in front of it. The orchestrator turns them into a new ticket and places it in the milestone, so the plan grows by one ticket on its own.

The A project, end to end page follows a TypeScript app through this loop. The checks below come from that project.

What to look at in a Node/TypeScript pull request

• The ticket’s acceptance checks. Read the milestone’s checks first, then ask whether this pull request meets them. A small feature should meet its own ticket’s checks and nothing more.
• Tests and CI. The first milestone of the worked project put Vitest, unit tests for the changed logic and a CI check on every pull request in place. Confirm the new behaviour has tests and that CI ran on the pull request and is green.
• Node version fit. In the worked project, the config file the working doc named, vitest.config.ts, failed to load on the repo’s Node version, so the builder used vitest.config.mts. The CI job for database tests also ran on the same Node version as the unit tests. Check that config files, scripts and CI use a Node version the repo actually runs.
• Existing data. In the worked project, the builder left existing data alone, flagged it in the pull request and left any production fix to the person. Check that a feature does not rewrite data it was not asked to touch, and that anything left open is named.
• The pull request description. The builder rewrote an existing description into the documented sections instead of appending to it. Check that the description says what changed and why.
• Choices the plan did not cover. When the crew meets something the plan does not cover, it picks a sensible answer and records it as an assumption. Check that such choices are written down so you can keep or reject them at the end of the milestone.

Set it up

1. Write acceptance checks that a reviewer can test. They live on the milestones in the spec, and the reviewer measures every pull request against them. Name the test runner, the CI check and the Node version you expect.
2. Check the prerequisites from Get started: Claude Code signed in, gh signed in with write access to the repos, and git, jq and curl installed.
3. On a local Tares, start Tares and the MCP endpoint the crew shares. Then bring up the crew and plan the project:

tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

Run tares mcp in a second terminal. On Tares Cloud, run tares login instead and skip the MCP step. 4. Choose at crew up how far the crew may go. The How far the crew may go panel on the Crew page (http://127.0.0.1:8787/crew locally) shows what you chose, including whether the crew merges on its own after a passing review and green CI. 5. Watch the review queue on the Crew page for pull requests waiting for the reviewer. Open the project page to read each ticket with its pull request and review rounds. 6. Answer the crew’s questions in the orchestrator’s session. Your answers appear in the Decisions fold as you typed them.

What you get

• Every small feature gets a recorded verdict against its ticket’s acceptance checks before it merges.
• Review rounds show on the ticket, so you can see which pull requests needed changes and which passed first time.
• Issues the reviewer finds outside the ticket become their own ticket instead of being lost or bundled into the feature.
• Assumptions about Node versions, config files and existing data are recorded, and the orchestrator brings them to you together at the end of each milestone.
• The project page keeps the whole record: tickets, pull requests, decisions and assumptions.

When something else fits

• If you want to approve each merge yourself, choose that at crew up. The worked project’s second example waited for the person’s yes before every merge.
• If a change is large or touches data and production, keep it in your own hands. The builder flags such things in the pull request and leaves production fixes to you.
• To steer work already in flight, talk to the orchestrator.

Related