What kinds of questions does a Claude Code crew ask me during a project?

A Claude Code crew in Tares asks you two kinds of questions: steps only you can take on your machine, and end-of-milestone checks on the choices it made on its own. The example project raised five, two of the first kind and three of the second. You answer them in the orchestrator’s session.

How it works

The crew works through tickets on its own: a builder opens a pull request for each ticket, the reviewer posts a verdict, and the builder merges once the verdict passes and CI is green. The orchestrator answers the builders and brings you only what needs you, as a question in its session. The two kinds of question come from different causes.

Steps only you can take on your machine. Some actions cannot be done by a session on your behalf. In the example project there were two:

• Trusting the repo folder in Claude Code once, so the builder could start.
• Giving Tares a GitHub token, so it could read pull request, CI and merge state.

End-of-milestone questions. When the crew meets something the plan does not cover, it picks the 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: do you keep the choices the crew made on its own during this milestone? The example project had three milestones, so it had three of these questions.

The assumptions in that project show what you are being asked to keep:

• The working doc named vitest.config.ts, which fails to load on the repo’s Node version, so the builder used vitest.config.mts.
• Sitters already inactive in production kept open-ended slots. The builder left existing data alone, flagged it in the pull request and left any production fix to the person.
• The reviewer’s smaller findings became a new ticket, T8.
• The CI job for database tests ran on the same Node version as the unit tests.
• Pull request #1 already had a description, so the builder rewrote it into the documented sections instead of appending.

The person kept all five. Mid-build, assumptions stay open, and each one names the tickets it touches and the builder that made it.

Two more questions come at the end. After the last milestone, the orchestrator asks whether the project is finished. With no project left, it asks whether to stop the crew. A project can also be set up to wait for your yes before every merge, and then most of its questions are merge approvals.

Set it up

1. Check the prerequisites and install the CLI as described in Get started. On a local Tares, start Tares and the MCP endpoint first.

2. Bring up the crew, then plan a project. The spec session ends by asking whether to hand the project to the crew, and the orchestrator picks it up from there.

tares factory crew up
tares factory spec "what you want to build"

3. Open the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares. Questions waiting for you appear at the top. The project page lists them too, under questions waiting for you.

4. Answer in the orchestrator’s session. When the question is a machine step, such as trusting the repo folder or giving Tares a GitHub token, take the step and tell the orchestrator. When it is a milestone question, say which assumptions you keep.

5. To make an answer stand from now on, say so, for this project or for every project.

6. When the project is done, answer whether it is finished. Run tares factory crew down to stop every station, and crew up when you have the next project.

What you get

• A short list of questions that need a person. The crew does not ask about every small choice. It decides, records the choice and asks you once per milestone.
• A record of every question and your answer. The Decisions fold on the project page holds each question the crew asked you and your answer in your own words, newest first.
• A record of every choice the crew made on its own. The Assumptions fold lists each one and whether you kept it, with the tickets it touches and the builder that made it.
• Control over how far the crew goes. The Crew page shows what you chose at crew up, such as whether the crew merges on its own once the reviewer passes a pull request and CI is green.
• A finish you control. Tares marks the project Done with the words you gave when you said it was deployed and working, and moves it to the finished list on the Crew page.

The full walkthrough, including the project’s eight merged pull requests, is in A project, end to end.

When something else fits

• To steer the work between questions, talk to the orchestrator in its session. You do not have to wait for a milestone to end.
• To review the crew’s choices later, open the Decisions and Assumptions folds on the project page rather than scrolling back through a session.
• To pick up a finished project again, hand it to the crew again, for example with a follow-up spec.

Related