Who writes the spec when the work is framework migrations?
Tares writes it with you in a spec session: you run tares factory spec in the repo, and Claude Code interviews you one question at a time. The session writes the spec, the plan, the project’s AGENTS.md and the milestones with their acceptance checks. A framework migration goes through the same flow as any other project, and the crew builds from those documents once you say yes.
How it works
The spec session is a Claude Code session that starts in your repo. It asks you questions one at a time, and your answers shape the result.
A second model challenges the plan before it is final. The result goes into Tares as four things:
- The spec, the statement of what the project must achieve.
- The plan, how the work is broken down.
- The project’s AGENTS.md, which every session that builds the project reads.
- The milestones, each with acceptance checks.
In the example project in A project, end to end, the person ran tares factory spec, answered the questions, and ended up with a spec, a plan, an AGENTS.md and three milestones. One milestone covered tests and CI on the branch. One covered keeping past data as it was. One covered merging and going live. Your migration gets its own milestones in the same way, each with its own checks.
At the end of the session you say yes to handing the project to the crew. The orchestrator picks it up and starts a builder for the first milestone. The builder works through the tickets one at a time, making a branch and opening a pull request for each. The reviewer reviews every pull request, and the builder merges once the verdict passes and CI is green.
Set it up
Follow these steps in order. Steps marked local apply to a local Tares, and steps marked cloud apply to Tares Cloud.
- Check that Claude Code is signed in, that
ghis signed in with write access to the repos the crew works in, and that git, jq and curl are installed. - Install the CLI with
uv tool install tares, or withbrew install glassflow/tap/tares. - Local: start Tares with
tares up. - Local: in a second terminal, start the MCP endpoint every crew session shares with
tares mcp --transport streamable-http. - Cloud: sign in with
tares loginand pick your workspace in the browser. - Give Tares access to GitHub. On a local Tares use Settings > GitHub, and on Tares Cloud use Connect GitHub.
- Bring up the crew with
tares factory crew up. - In the repo you want to migrate, start the spec session and describe the migration you want.
tares factory spec "what you want to build"Answer the questions as they come. When the session finishes, you have the spec, the plan, the AGENTS.md and the milestones. Say yes to hand the project to the crew. If you are new to the factory, Get started walks through the full setup.
What you get
- A written record of the work. The project page has a Docs fold with the starting prompt, the spec, the plan and the project’s AGENTS.md. You can edit any of them there.
- Milestones you can check. The Tickets fold lists each milestone with its acceptance checks, and each ticket with the builder that held it, its pull request and its review rounds.
- Your answers on file. The Decisions fold holds every question the crew asked you and your answer in your own words, newest first.
- Choices the crew made on its own. The Assumptions fold lists each one. At the end of each milestone the orchestrator brings them to you in one question, and you decide whether to keep them.
- A crew that builds from the same documents. Every session that builds the project reads the spec, the plan and the AGENTS.md, so the builders and the reviewer work from one shared brief.
You can watch progress on the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares.
When something else fits
- If you want to steer a build already in progress, talk to the orchestrator instead of starting a new spec session. It answers the builders and brings you what needs you.
- To pick up a finished project again, hand it to the crew again, for example with a follow-up spec.