A small thing I almost shipped wrong in worktree-orchestrator: nothing removes a worktree for you.
When an agent's task finishes, the branch merges, the worktree directory is still sitting on disk, and git worktree list still shows it. Leave enough of these around and two things go wrong. Disk fills up slowly and invisibly, because each worktree is a full checkout, not a symlink. And worse, a later agent session can cd into a stale worktree by mistake and start working on a branch that already merged, producing changes nobody asked for against code that no longer needs them.
The fix is one command, git worktree remove, but it has to actually run as part of the task's completion step, not as a "clean up later" afterthought. I now treat an unremoved worktree the same way I treat an unreleased task lease: it is not a small papercut, it is a resource with no owner, and something has to be responsible for closing it out.
git worktree prune catches the ones where the directory is already gone but git does not know it yet. I run it on a schedule now, alongside the explicit removal step, because "I will remember" is not a cleanup strategy.