Multi-repo workflows: repo picker + global worktree switch/list (and expose `project_identifier` to templates)

[prateek]

Summary

I use Worktrunk daily, but across many repositories, and I’d love guidance (or upstream support) for “multi-repo” workflows: pick a repo, then create/switch/list worktrees without first cd’ing into that repo.

Worktrunk’s per-repo UX is excellent (wt switch picker, wt list --full, hooks, CI links). The gap for me is “which repo?” + “show/switch existing worktrees across repos”.

Current workaround (wrapper)

I wrote a thin zsh wrapper w that:

• Selects a repo (fzf over a local index of canonical clones)
• Sets a centralized worktree root per invocation (so worktrees from many repos live under one root)
• Defers the core operations to Worktrunk (wt -C <repo_root> switch …)

It also adds:

• w <branch> → create/switch + cd (multi-repo by default)
• w <branch> -- <agent args…> → create/switch + run an agent command (via wt switch -x …)
• w switch → fzf-pick an existing worktree directory (across repos) and cd into it
• w ls → a lightweight cross-repo listing for the centralized root (coarse; rich status still comes from wt list)

Wrapper code/docs (for concrete context):

• https://github.com/prateek/dotfiles/blob/master/zsh/autoload/w
• https://github.com/prateek/dotfiles/blob/master/zsh/autoload/repo_select
• https://github.com/prateek/dotfiles/blob/master/docs/worktrees.md

Questions / potential upstream improvements

1. Is a wrapper the intended approach for multi-repo workflows?

If yes: are there recommended extension points (config conventions, helper commands, JSON output fields, etc.) to make wrappers more robust?

2. Expose a “repo slug” to templates

Worktrunk already has a stable “project identifier” (used for [projects."…"] and approvals), typically like github.com/owner/repo.

Could Worktrunk expose something like:

• {{ project_identifier }} (or {{ project }} / {{ repo_slug }})

…as a template variable for worktree-path (and/or hook templates)?

This would make it easy to create a collision-free centralized layout across many repos (and hosts) without custom code:

# ~/.config/worktrunk/config.toml
worktree-path = "~/code/wt/{{ project_identifier | sanitize }}/{{ repo }}/{{ branch | sanitize }}"

Today, a centralized template like ~/worktrees/{{ repo }}/{{ branch | sanitize }} can collide if you have multiple repos with the same directory name.

3. Optional multi-repo list/switch

Would you be open to an opt-in “workspace” concept, e.g.:

• wt list --workspace <dir>: scan a centralized worktree root and show an aggregated table (maybe by grouping by git common dir / repo)
• wt switch --workspace <dir> (or --repos-from <file|cmd>): interactive picker over (repo, branch) pairs

Even if it’s out of scope, I’d love to know if there’s a preferred direction.

Notes

• I searched issues for “multi repo”, “workspace”, “global list”, “repo picker”, etc. and didn’t see an obvious duplicate; happy to be pointed at an existing thread if I missed it.
• This issue is intentionally sanitized (no private repo names/paths); I can provide more details if useful.
• This draft was generated with the help of AI tools and then reviewed by a human; any mistakes or “slop” are the human author’s responsibility.

[max-sixty]

thanks for the thoughtful issue!

I have the same issue, wanting a "how are all my workstreams going"

but worktrunk is currently very orientated around a single repo; even concepts such as a single default branch. It would be a huge change to make it multi-repo, and my sense is that it would be greater than the immediate gain.

so:

• we could add repo slugs to templates — could you explain what would be useful which we don't have now?
• folks are welcome to use the wt list code to make something more focused on multi-repo. I can make more things public in the rust interface
• any other ideas that I missed above?

[richraid21]

I opened another feature ticket for this by accident. I was hoping we could agree on a path forward (or whether it should be an aggregating tool rather than built into worktrunk). I'm happy to contribute.

[prateek]

@max-sixty @richraid21 I had meant to respond to this issue once I had done more to figure out a path forward but since I'm seeing a bit more activity, I'll share rough thinking to get initial gut-check/feedback.

re: path forward being extending worktrunk v making a new cli tool. Regardless of which path we take, I wanted to have an idea for what the code changes involved would look like. So I got a LLM to prototype one possible solution based on the following spec. (Caveat: both the PRD+implementation have warts still, I haven't really cleaned it up/made it good enough to be my daily driver yet.)

The prototype lives at: https://github.com/prateek/w. Callouts:

• It includes the worktrunk code-base as a squashed git subtree (it pulled eb9023a030ccee5b3a1a3a03086ad25472f85eba but that's easily updatable because we do maintain the worktrunk code in a vendor/ isolated path)
• It extended/made as few changes to worktrunk as possible to expose a library interface into worktrunk functionality
• Makes a new cli rust based tool which relies on the library interface to expose the multi-repo functionality

That code is very much fine for you two (or anyone) to do whatever you want with. Only offering it as an update of where my thinking is at. @max-sixty I will defer to your judgement/preferences for next steps. My preference would be to get that codebase into something that meets both your and my "good enough" quality bar (UX/code quality/etc) and then have it merged into worktrunk to keep the ux simpler for end-users and keep it all in the same repo and so on but I can understand the opposing viewpoint too.

lmk what you think

[richraid21]

Thanks @prateek I will give this a read through. I appreciate the MVP/getting something working to kickstart a discussion.

[max-sixty]

@prateek thanks! the plan sounds reasonable. I still think it needs a lot of work: the installation instructions don't work, it seems to have forked a bunch of the basic functionality and renamed commands etc, but that's quite reasonable at this stage, and no judgement given I only spent a few minutes with it

I am keen to be as helpful as possible: it's totally reasonable to vendor wt and fork it, and then later we could try and integrate it back iff the author wants (their decision!)

I would estimate this is going to require someone who really cares to spend a decent amount of time making it good, making difficult tradeoffs, thinking deeply about the problems, etc...

[Lewenhaupt]

Would love this feature!

[max-sixty]

I will close as I'm not sure there is much to do here, but I remain open to supporting anyone who wants to build it