Worktrees
Route /worktrees. Parallel work: several agents on one repository at once, each in its own git worktree, merged back when they are done.
Starting a run
A run needs three things.
- Session — the thread it belongs to. The picker lists every open session by project, id and mode. New session… opens a folder picker if the repository you want is not there yet.
- Workers — how many agents work in parallel, and therefore how many worktrees are created.
- Task — what they are collectively doing, in a sentence.
Start team runs /team N "<task>" in that thread. It is deliberately the same command a person would type, so the transcript in the thread is a complete record of the run.
The repository must have at least one commit. Team mode branches off HEAD, and there is nothing to branch from in an empty repository.
The board
The board is a read model. The core plans the work into tasks, and each task moves through columns as its state changes: planned, running, review, merged. The worktree count above the board is how many are open right now, which falls back to zero as the run finishes and the worktrees are removed.
Expanding a task shows its branch, its worktree path, and — when a merge did not apply cleanly — the conflicting hunks.
History on the right keeps the runs from this session, newest first. Selecting one puts its board back on screen.
When a merge conflicts
A conflicted task stops in review rather than merging. The hunks are shown so you can decide what happened; resolving it is a git operation in the worktree the task names, not something this screen does for you.