Skip to Content

Where can I read back what the crew decided during internal refactors in a monorepo?

Tares keeps the record on the project page, which every project you hand to the crew gets. Open its Decisions fold for every question the crew asked you and your answer in your own words, newest first. Open Assumptions for the choices the crew made on its own, Tickets for the work, and Sessions for the recorded Claude Code sessions.

How it works

Every project you hand to the crew gets a page of its own, the record of the whole build. Open the Crew page in the console (http://127.0.0.1:8787/crew locally), then open the project. Each part of the record folds open. For an audit trail of what was decided, four folds matter:

FoldWhat it holds
DecisionsEvery question the crew asked you and your answer, in your own words, newest first. A recorded answer holds up to 4,000 characters.
AssumptionsEvery choice the crew made on its own, and whether you kept it.
TicketsMilestones with their acceptance checks, and each ticket with the builder that held it, its pull request and its review rounds.
SessionsThe recorded Claude Code sessions, from the spec session to each builder.

The GitHub fold also lists the repos the project changes, where each is checked out, and its open and merged pull requests. The project page works the same way for any project, so the same folds hold the record of an internal refactor.

Your answers. You answer the crew’s questions in the orchestrator’s session. The answer goes into the Decisions fold as you typed it. Tares finds your answer in your session by matching it line by line, so a long pasted reply with several lines or paragraphs matches in full. Tares keeps up to 20,000 characters of your turn for this, and the tags Claude Code wraps around pasted text do not stop a match. A reply stored before Tares fixed this stays cut. Paste the missing lines once more.

The crew’s own choices. When the crew meets something the plan does not cover, it picks the sensible answer, writes it down as an assumption, and carries on. Mid-build, assumptions are still open, and each one names the tickets it touches and the builder that made it. At the end of each milestone, the orchestrator brings you its assumptions in one question, so you decide whether to keep them. To make an answer stand from now on, say so, for this project or for every project.

Set it up

  1. Plan the project from the repo with the spec command. You answer Claude Code’s questions, and the result goes into Tares as a spec, a plan, an AGENTS.md for the project and milestones with acceptance checks.
tares factory spec "what you want to build"
  1. Say yes when asked to hand the project to the crew. The orchestrator picks it up and starts a builder for the first milestone. If you have not set up the factory yet, start with Get started.
  2. Answer the crew’s questions in the orchestrator’s session. Questions waiting for you also appear at the top of the Crew page and on the project page under questions waiting for you.
  3. Open the project page and unfold Decisions to read each question with your answer as typed, newest first.
  4. Unfold Assumptions to see what the crew chose without asking you, and whether you kept it. Keep or change each one when the orchestrator brings them to you at the end of a milestone.
  5. Unfold Tickets to see each ticket with the builder that held it, its pull request and its review rounds. Unfold Sessions to open the recorded Claude Code sessions behind the work.

The page A project, end to end walks through a finished project with all of these folds filled in, including five decisions (D1 to D5) and five assumptions (A1 to A5).

What you get

  • A written record of every question the crew asked you, with your answer in your own words and not a paraphrase.
  • A list of every choice the crew made on its own, each marked as kept or not, so nothing it decided without you is hidden.
  • Tickets that show who built what, with the pull request and the review rounds. A ticket can pass on the first round, or take a second when the reviewer asks for changes.
  • Recorded sessions, from the spec session to each builder, for when you want the full detail behind a decision or a ticket.
  • A project that stays readable after it is done. Tares keeps the projects, tickets and answers, even after you run tares factory crew down, and a finished project sits folded in the finished list on the Crew page.

When something else fits

  • For a quick view of what moved across projects, use Standup on the Crew page. It reports what is done, started, in review, blocked and waiting on you, with pull request links.
  • For the live state of each station, use the Crew page and its stations list, not the project page. The project page is the record, and the Crew page shows who is working now.
  • To record a decision with a lasting effect, say in your answer that it should stand from now on, for this project or for every project.

Still stuck? Get help

Last updated on