What should the first ticket be when I hand internal refactors to a Claude Code crew?

With Tares, make the first ticket for internal refactors the smallest change a builder can finish and the reviewer can check against the milestone’s acceptance checks. Tickets sit under milestones, and each milestone carries its own acceptance checks. A small first ticket gives you one quick pull request, one review verdict and an early look at how the crew works on your code.

How it works

Tares plans a project in a spec session. You run tares factory spec in the repo and answer Claude Code’s questions. The result is a spec, a plan, an AGENTS.md for the project and milestones, each with acceptance checks. Tickets sit under those milestones.

Once you hand the project to the crew, the orchestrator picks it up and starts a builder for the first milestone. From there:

• The builder works through the tickets one at a time. For each, it makes a branch, does the work and opens a pull request.
• The reviewer reviews every pull request and posts its verdict.
• Once the verdict passes and CI is green, the builder merges.
• Each ticket shows its state: to do, in progress, in review, merged or blocked. A blocked ticket names the tickets it waits for.

The first ticket sets the pattern for the rest, so its size matters. A ticket the builder can finish in one branch gives the reviewer a bounded pull request to check against the acceptance checks.

The A project, end to end page shows a first milestone of this kind. Its M1 was tests and CI on the branch: Vitest, unit tests for the babysitting logic, and a CI check on every pull request. It was small, and each part could be checked.

Set it up

New to the software factory for Claude Code? Start with Get started for the full setup. Then shape the first ticket like this.

1. Describe the refactor in one sentence when you start the spec session. Name the module or area, not the whole codebase.

tares factory spec "what you want to build"

2. In the spec session, ask for the first milestone to hold the smallest change you can name. Ask for acceptance checks the reviewer can verify from the pull request, such as tests that pass, CI that is green, or a behavior that stays as it was.
3. Before you say yes to handing the project over, open the project page and read the Tickets fold. It lists the milestones with their acceptance checks. Check that the first ticket is one a builder can finish in a single pull request, and that each check is something a reviewer can confirm.
4. If the first ticket is too wide, say so in the spec session and have it split. Aim for tickets that do not depend on one another, since a blocked ticket waits on the tickets it names.
5. Say yes to hand the project to the crew. Bring the crew up if it is not running.

tares factory crew up

6. Watch the first pull request on the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares. Read the reviewer’s verdict and the review rounds shown with the ticket.

Answer the crew’s questions in the orchestrator’s session. Your answers are kept in the Decisions fold as you typed them.

What you get

• A first pull request you can judge quickly, with a reviewer verdict against stated acceptance checks.
• A visible record on the project page: the ticket, the builder that held it, its pull request and its review rounds.
• Most tickets in the example project passed review on the first round, and two took a second round, where the reviewer asked for changes and the builder made them. A small first ticket makes a second round cheap.
• Room for the plan to grow. When the reviewer finds smaller issues outside the ticket it is reviewing, the orchestrator turns them into a new ticket in the milestone, as it did with T8 in the example project.
• Assumptions the crew makes on its own are written down. The orchestrator brings them to you together at the end of the milestone, and a small first milestone gets you to that check early.

When something else fits

• If the refactor cannot be cut into a change a reviewer can check on its own, work through it in the spec session first, so the milestones and acceptance checks say what done means before the crew starts.
• If a change needs your judgment at every step, keep it in your own Claude Code session and hand the crew the parts with clear acceptance checks.

Related