How should I split small features into milestones for a Go microservice?

Tares plans a project as milestones, each with acceptance checks, and you split small features so that each milestone ends at something you can check. Group the features by what you can confirm together, and give each group its own milestone. The end of a milestone is where the crew brings you the assumptions it made, so you can keep or change them. The Get started page covers the setup, and the sections below cover the split.

How it works

The software factory for Claude Code plans a project as a spec, a plan, an AGENTS.md and a few milestones. Each milestone carries acceptance checks. Inside a milestone the work is broken into tickets. A builder takes the tickets one at a time, makes a branch for each, does the work and opens a pull request. The reviewer reviews every pull request, and the builder merges once the verdict passes and CI is green.

The project end to end walkthrough shows the shape. Its three milestones were:

• M1, tests and CI on the branch. A test runner, unit tests for the logic and a CI check on every pull request.
• M2, payout history stays as it was. A behavior that must hold, such as past weeks not changing when a rate changes.
• M3, merged and live. The change documented, merged into main and running in production.

Each milestone names an outcome you can confirm, not a list of tasks. Apply the same idea to your Go microservice. Make your small features the tickets, and make the milestones the points where you can say yes, this works.

A milestone’s end is also where assumptions get settled. When the crew meets something the plan does 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 its assumptions in one question, and you say whether to keep them. Each assumption names the tickets it touches and the builder that made it.

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.
2. Install the CLI, start Tares locally and start the MCP endpoint every crew session shares. On Tares Cloud, run tares login instead and skip the local start and the MCP endpoint.
3. Give Tares access to GitHub: Settings > GitHub for a local Tares, or Connect GitHub on Tares Cloud.
4. Bring up the crew, then plan the project from your Go repo.

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up
# in a second terminal:
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

5. In the spec session, answer Claude Code’s questions about your features. A second model challenges the plan, and the result goes into Tares as a spec, a plan, an AGENTS.md and milestones, each with acceptance checks.
6. Before you hand the project over, read the milestones on the project page, in the Tickets fold. Check that each milestone ends at something you can confirm, and that the features inside it belong together. If a milestone mixes unrelated outcomes, split it.
7. Say yes to handing the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.

A few rules of thumb for the split:

• Put the groundwork first, such as tests and a CI check on every pull request, as the example’s M1 does. Later milestones then have something to check against.
• Keep one behavior you care about in each milestone, such as existing data staying as it was.
• Finish with a milestone for merged and live, so the last check is real.
• Keep a milestone to a size where you can review its assumptions in one sitting.

What you get

• Milestones that each end at a check you can confirm, shown with their acceptance checks in the Tickets fold of the project page.
• One question per milestone for the choices the crew made on its own. You keep them or change them, and the Assumptions fold records each choice and whether you kept it.
• A pull request per ticket, each reviewed before it merges, so small features land as small changes you can follow.
• A plan that can grow. In the example, the reviewer found smaller issues, and the orchestrator turned them into a new ticket and placed it in M2 before the integration tests.
• A record of every answer you gave, in your own words, in the Decisions fold.

When something else fits

• If you have a single small change with no checks worth separating, one milestone with a couple of tickets is enough. More milestones add more questions to answer.
• If a feature depends on another, keep them in the same milestone or order them so the dependency is clear. A blocked ticket names the tickets it waits for.
• If your work spans several repos, the project page’s GitHub fold lists each repo the project changes, so you can split milestones by outcome across them.

Related