Can I take over bug fixes from the crew halfway and finish it myself?

Yes, Tares lets you take a project over from the crew and finish it in your own Claude Code session. Run tares factory session and say yes when it asks about taking the project over. The crew stops, and your session carries on from the branches and pull requests the builders left, so the bug fixes continue where they stopped.

How it works

The software factory for Claude Code keeps its record on Tares, not in the crew’s sessions. Tares holds the plan, the tickets and their stages, every review, the assumptions the crew made, the questions it asked you and your answers. Because of this, a different session can pick up the work without starting over.

When you open a session on a project the crew has, the session asks whether to take it over:

• Yes: the crew stops. Its builders push what they have and write their progress. Your session then continues from their branches and pull requests.
• No: the crew keeps the project and nothing changes.

The session you open is Claude Code with the Tares plugin, bound to the project. Your shared AGENTS.md and memory apply, and the session’s record lands on the project, next to what the crew already wrote. A plain claude has no Tares tools, so start these sessions with the Tares command, not by running claude directly.

Tickets stay where they live. If the project keeps its tickets in Linear or GitHub Issues, your session changes them with its own tools, and Tares only reads them.

Set it up

1. See what the crew has. List the projects handed to the crew, with their progress, builders and repos:

   tares factory projects

2. Check the stations and what is waiting for you. The Crew page in the Tares console shows the same, including the pull requests waiting for review:

   tares factory crew status

3. Open your own session. Run the session command with no argument and pick the project that holds your bug fixes from the list. You can also pass the project name after the command.

   tares factory session

4. When the session asks whether to take the project over, say yes. The builders push their work and write their progress, and the crew stops for that project.

5. Work from the branches and pull requests the crew left. Review them, push to them and merge them the way you normally would, with your own gh login. Update the tickets as you go.

6. When the work is done, mark the project done yourself with tares factory finish, followed by the project and a few words of your own.

If you have not set up the crew yet, or the command is not found, the Get started page covers installing the CLI, starting Tares and bringing up the crew. Run tares factory doctor if a session does not start as expected, and it prints the fix for each problem it finds.

What you get

• No lost work. Builders push what they have before they stop, so the branches and pull requests hold the crew’s progress.
• No two hands on the same work. Once you say yes, the crew stops, so the crew’s builders do not keep pushing to the branches you are finishing.
• Context that carries over. The plan, tickets, reviews, assumptions and your earlier answers stay on Tares, and your session works from that record.
• One record. Your session’s work lands on the same project, so the history shows both the crew’s steps and yours.
• Your choice. Say no at the prompt and the crew keeps the project, so you can look first and decide later.

This works the same way for any project the crew holds, so it applies to your bug fixes as it does to a feature project.

When something else fits

• If you only want a pause, not a hand-over, tares factory crew halt stops merges, pushes and new sessions until tares factory crew resume, and the crew carries on afterward.
• If you want to stay in the loop without taking over, answer the crew’s questions in the orchestrator with tares factory crew attach. A project can also wait for your yes before every merge while the rest of the crew merges on its own.

Related