What should the first ticket be when I hand dependency upgrades to a Claude Code crew?

In Tares, make the first ticket the smallest upgrade a builder can finish in one pull request and the reviewer can check against its acceptance checks. Tickets sit under milestones, and each milestone carries acceptance checks. A small first ticket gives you one quick pass through build, review and merge before the larger upgrades follow. You see how the crew works on your repo before you trust it with more.

How it works

The software factory for Claude Code turns your request into a spec, a plan, an AGENTS.md for the project and milestones, each with acceptance checks. Tickets sit under those milestones. The same flow applies to dependency upgrades as to any other project.

• Builder. It works through tickets one at a time. For each one it makes a branch, does the work and opens a pull request.
• Reviewer. It reviews every pull request and posts a verdict. Once the verdict passes and CI is green, the builder merges.
• Review rounds. Most tickets pass on the first round. If the reviewer asks for changes, the builder makes them and the next round is checked.
• Orchestrator. It starts a builder for the first milestone and brings you the questions that need you. It can also add tickets. In the example project, the reviewer found smaller issues outside its ticket, and the orchestrator turned them into a new ticket placed in the right milestone.

Because the reviewer judges a pull request against the acceptance checks, the first ticket works best when it is small and its checks are easy to state. A good first ticket for an upgrade project has three traits:

• It is one change a builder can finish and open as one pull request.
• It has a clear pass or fail, such as the existing CI running green on the pull request.
• If it fails, the pull request is easy to read and revert, and the review round shows exactly what to fix.

The project in A project, end to end shows the same idea. Its first milestone was tests and CI on the branch, so every later pull request had something to be checked against.

Set it up

1. Set up the crew by following Get started, then bring it up:

   tares factory crew up

2. In the repo whose dependencies you want to upgrade, plan the project and answer Claude Code’s questions:

   tares factory spec

   A second model challenges the plan. The result goes into Tares as a spec, a plan, an AGENTS.md and milestones with acceptance checks.

3. Say in your answers that the first ticket is a single upgrade, for example one dependency with a small surface. Ask for its acceptance checks to be plain, such as CI green on the pull request. Leave the larger upgrades to later tickets in the same or later milestones.

4. Check the milestones and acceptance checks before you say yes to handing the project to the crew. The orchestrator then picks it up and starts a builder for the first milestone.

5. Open the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares, and open the project page. In the Tickets fold, each ticket shows its state (to do, in progress, in review, merged or blocked), the builder that held it, its pull request and its review rounds.

6. Once the first ticket is merged, look at how it went: how many review rounds it took and what the reviewer asked for. Use that to decide how large the next tickets can be. To steer the work, talk to the orchestrator.

What you get

• A first ticket that one builder can finish and the reviewer can check against written acceptance checks.
• A visible record on the project page of that ticket’s builder, pull request and review rounds, so you see how the crew handles your repo early.
• Blocked tickets that name the tickets they wait for, so later upgrades that depend on the first one are ordered for you.
• Questions brought to you by the orchestrator, and your answers kept in the Decisions fold in your own words.
• Choices the crew makes on its own recorded as assumptions, which the orchestrator brings to you together at the end of each milestone.

When something else fits

• If the repo has no tests or CI, make the first milestone tests and CI, as the example project did, so later upgrade pull requests have checks to meet.
• If you would rather approve each step yourself, you can set the project up so the crew waits for your yes before every merge. The example project mid-build did this, and its decisions were mostly merge approvals.
• If the first ticket needs more than one pull request to finish, split it. A ticket the reviewer cannot check against its acceptance checks is too big to go first.

Related