How should I split small features into milestones for a monorepo?
Tares plans a project as a few milestones, each with acceptance checks, and you split small features so that each milestone ends in something you can verify. The small features become tickets inside a milestone. At the end of each milestone the orchestrator asks you to confirm the choices the crew made on its own, and the next milestone starts from there.
How it works
When you run tares factory spec, Claude Code asks you questions and a second model challenges the plan. The result goes into Tares as a spec, a plan, an AGENTS.md for the project and milestones, each with acceptance checks. When you say yes, the orchestrator picks up the project and starts a builder for the first milestone.
Inside a milestone, the builder works through the tickets one at a time. Each ticket gets a branch and a pull request. The reviewer posts a verdict on every pull request, and once the verdict passes and CI is green, the builder merges. A blocked ticket names the tickets it waits for.
The milestone is also where you check in. When the crew meets something the plan does not cover, it picks a sensible answer, records it as an assumption and carries on. At the end of each milestone the orchestrator brings you all of that milestone’s assumptions in one question. Each assumption names the tickets it touches and the builder that made it. You keep them or not, and your answer goes into the Decisions fold in your own words.
Here is how the example project on A project, end to end split its work into three milestones:
- M1, tests and CI on the branch: the test setup, unit tests and a CI check on every pull request.
- M2, payout history stays as it was: past weeks stay as they were when a sitter or a rate changes.
- M3, merged and live: the pull request documented, merged into main and running in production.
Set it up
- Check the prerequisites from Get started: Claude Code is signed in, gh is signed in with write access to the repos the crew works in, and git, jq and curl are installed. On a local Tares, start Tares and the MCP endpoint first, as Get started shows.
- Bring up the crew.
- Run the spec in the repo and describe the small features you want built. You can list them in the prompt.
tares factory crew up
tares factory spec "what you want to build"- Answer Claude Code’s questions. When you review the milestones it proposes, shape them with these rules:
- Make each milestone one outcome you can check, and write its acceptance checks so you can tell yes from no. Setting up tests and CI is a good first milestone, because later tickets build on it.
- Group the small features into a milestone by what you can verify together. Each feature becomes a ticket with its own pull request.
- Give existing behavior you want to protect its own milestone, as M2 did for payout history.
- Make the last milestone about getting the work merged and live.
- Keep milestones few. The example had three milestones for eight tickets. A larger project had 20 tickets over three milestones.
- Say yes to hand the project to the crew. The orchestrator starts a builder for the first milestone.
- At the end of each milestone, answer the assumptions question. To make an answer stand from now on, say so, for this project or for every project.
What you get
- Milestones with acceptance checks on the project page, in the Tickets fold, with each ticket’s builder, pull request and review rounds.
- One question per milestone that confirms the assumptions made during it, recorded in the Assumptions fold. In the example, the person kept all five.
- A plan that adjusts as it builds. In the example, the reviewer found smaller issues outside the ticket it was reviewing. The orchestrator turned them into a new ticket and placed it inside M2, before the integration tests.
- A progress bar with one segment per ticket, and a Decisions fold holding every answer you gave.
- A clear finish. After the last milestone the orchestrator asks whether the project is done, and Tares marks it Done with your words and every ticket merged.
When something else fits
- To change the plan mid-build, talk to the orchestrator. To see where the crew stands without opening a session, use the Crew page and its Standup report.
- To pick up a finished project again, hand it to the crew again, for example with a follow-up spec. Start a new spec instead of stretching the old milestones.