How should I split small features into milestones for a Node/TypeScript app?

Tares plans a project as milestones, each with acceptance checks, so you split small features by the outcome you can check, not by file or layer. Each milestone ends with one question that asks you to confirm the choices the crew made on its own. Write checks that a reviewer and CI can pass or fail, and the crew can merge, ask and move on.

How it works

A milestone is the unit of planning. When you run tares factory spec in your repo, Claude Code asks you questions, a second model challenges the plan, and Tares stores a spec, a plan, an AGENTS.md for the project and the milestones, each with acceptance checks. The tickets sit under the milestones.

The project in A project, end to end shows the pattern. It started as a pull request with no tests and a few bugs, and it was split into three milestones:

• M1, tests and CI on the branch: Vitest, unit tests for the logic, and a CI check on every pull request.
• M2, payout history stays as it was: changing a rate or deactivating a sitter leaves past weeks untouched.
• M3, merged and live: the pull request documented, merged into main and running in production.

Each name states an outcome you can check, not an activity. Inside a milestone the builder takes the tickets one at a time. For each ticket it makes a branch, does the work and opens a pull request. The reviewer posts a verdict, and the builder merges once the verdict passes and CI is green.

The end of a milestone is also where the crew stops guessing. When it meets something the plan did not cover, it picks a sensible answer, writes it down as an assumption and carries on. At the end of each milestone the orchestrator brings you those assumptions in one question, and you keep them or not. In the example, the working doc named vitest.config.ts, which fails to load on the repo’s Node version, so the builder used vitest.config.mts and recorded it. The CI job for database tests ran on the same Node version as the unit tests. The person kept both.

Set it up

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. Install the CLI with uv tool install tares or brew install glassflow/tap/tares.
2. Start Tares locally, then in a second terminal start the MCP endpoint every crew session shares. On Tares Cloud you run tares login instead and there is no MCP endpoint to start.
3. Give Tares access to GitHub, in Settings > GitHub for a local Tares or Connect GitHub on Tares Cloud.
4. Bring up the crew, then plan the project from your repo:

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

5. In the spec session, shape the milestones as you answer Claude Code’s questions:
   • Group your small features by the outcome that proves they are done. A first milestone that puts tests and CI on the branch gives every later ticket something to be checked against.
   • Write each acceptance check as something a reviewer or CI can pass or fail. “Past weeks stay as they were” is a check. “Payouts are better” is not.
   • Put the step that ships the work, such as documenting, merging and deploying, in a milestone of its own, as M3 does.
6. When the plan looks right, say yes to handing the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.
7. Answer questions in the orchestrator’s session. Your answers land in the Decisions fold of the project page, and the assumptions the crew made land in the Assumptions fold, each with its tickets and the builder that made it.

What you get

• A project page with the Tickets fold listing every milestone with its acceptance checks, and every ticket with the builder that held it, its pull request and its review rounds.
• A confirmation point at each milestone. The crew’s own choices, such as a config file extension or a CI Node version, are brought to you together. To make an answer stand from now on, say so, for this project or for every project.
• A plan that can grow without you rewriting it. In the example the reviewer found smaller issues outside the ticket under review, and the orchestrator turned them into a new ticket, T8, placed in M2 before the integration tests.
• A progress bar with one segment per ticket, and a Standup report of what is done, in review, blocked and waiting on you.
• A clear finish. After the last milestone the orchestrator asks whether the project is done, and Tares marks it Done with your words. Run tares factory crew down to stop every station when no project is left.

The example project went from a spec to eight merged pull requests in about three hours, with five questions to the person. For the wider setup, see Get started.

When something else fits

• If you want to steer a single ticket yourself, talk to the orchestrator, which answers the builders and brings you only what needs you.
• If your features already live as Linear tickets or GitHub issues, Tares reads them as ticket sources, and the sessions update them with their own tools.

Related