Why
Investigation skills need codebase access — pressing i on a GitHub issue to understand what's involved requires exploring the actual source, not just fetching API data.
Current state
hub fetch maintains bare clones at ~/.hub/repos/<name>/ but creates no working tree. When i is pressed, launch_ci_investigation opens the skill in hub's own working directory (std::env::current_dir()). A skill investigating an issue in ooloth/dotfiles currently has no direct access to the dotfiles codebase.
Ideal state
hub fetch creates a linked worktree at ~/.hub/repos/<name>/<default-branch>/ for each project (e.g. main/, trunk/) immediately after cloning
- On each subsequent fetch, the default-branch worktree is reset to current HEAD so it is always clean and up to date
- The default branch name is detected from the bare clone's
HEAD symbolic ref — not hardcoded to main
- When
i is pressed on any item, the investigation skill opens in ~/.hub/repos/<name>/<default-branch>/ rather than hub's own directory
- The project name is resolved from the item's repo slug via a reverse lookup in
Config
- If no worktree exists for the item's project (e.g. the project was added to hub.toml but not yet fetched), the skill falls back to hub's own directory and flashes a warning
Out of scope
- Creating worktrees on-demand at
i press — the default-branch worktree is always pre-created by hub fetch
- Changing any skill logic or prompts
- Opening fix worktrees from
i — those are created separately when an agent begins a fix
Starting points
workflows/src/fetch.rs — fetch_project is where the worktree creation and reset belong
ui/tui/src/main.rs — launch_ci_investigation (line 490) and the i key handler (line 1387) are where the cwd is resolved and passed
config/src/lib.rs — Config struct with projects: Vec<Project> for the repo-slug-to-name reverse lookup
QA plan
- Delete
~/.hub/repos/ and run hub fetch — expect each project to have both a bare clone and a <default-branch>/ subdirectory; for ooloth/hub expect ~/.hub/repos/hub/main/
- Run
git -C ~/.hub/repos/hub/main status — expect a clean working tree on the default branch with no uncommitted changes
- Push a commit to a tracked repo, run
hub fetch again — expect the <default-branch>/ worktree to reflect that commit (git log -1 shows the new hash)
- Open the TUI and press
i on a CI failure for a known project — expect the investigation skill to open in ~/.hub/repos/<name>/<default-branch>/ (verify by checking the tmux pane's working directory with pwd)
- Press
i on a CI failure for a project whose slug maps to a known Config entry — expect the skill to open in the correct project's worktree, not hub's directory
- Temporarily remove a project's worktree directory, press
i on an item for that project — expect the skill to open in hub's directory and the status bar to flash a warning
Done when
Pressing i on any TUI item opens the investigation skill in the project's default-branch worktree at ~/.hub/repos/<name>/<default-branch>/.
Depends on
Why
Investigation skills need codebase access — pressing
ion a GitHub issue to understand what's involved requires exploring the actual source, not just fetching API data.Current state
hub fetchmaintains bare clones at~/.hub/repos/<name>/but creates no working tree. Wheniis pressed,launch_ci_investigationopens the skill in hub's own working directory (std::env::current_dir()). A skill investigating an issue inooloth/dotfilescurrently has no direct access to the dotfiles codebase.Ideal state
hub fetchcreates a linked worktree at~/.hub/repos/<name>/<default-branch>/for each project (e.g.main/,trunk/) immediately after cloningHEADsymbolic ref — not hardcoded tomainiis pressed on any item, the investigation skill opens in~/.hub/repos/<name>/<default-branch>/rather than hub's own directoryConfigOut of scope
ipress — the default-branch worktree is always pre-created byhub fetchi— those are created separately when an agent begins a fixStarting points
workflows/src/fetch.rs—fetch_projectis where the worktree creation and reset belongui/tui/src/main.rs—launch_ci_investigation(line 490) and theikey handler (line 1387) are where the cwd is resolved and passedconfig/src/lib.rs—Configstruct withprojects: Vec<Project>for the repo-slug-to-name reverse lookupQA plan
~/.hub/repos/and runhub fetch— expect each project to have both a bare clone and a<default-branch>/subdirectory; forooloth/hubexpect~/.hub/repos/hub/main/git -C ~/.hub/repos/hub/main status— expect a clean working tree on the default branch with no uncommitted changeshub fetchagain — expect the<default-branch>/worktree to reflect that commit (git log -1shows the new hash)ion a CI failure for a known project — expect the investigation skill to open in~/.hub/repos/<name>/<default-branch>/(verify by checking the tmux pane's working directory withpwd)ion a CI failure for a project whose slug maps to a knownConfigentry — expect the skill to open in the correct project's worktree, not hub's directoryion an item for that project — expect the skill to open in hub's directory and the status bar to flash a warningDone when
Pressing
ion any TUI item opens the investigation skill in the project's default-branch worktree at~/.hub/repos/<name>/<default-branch>/.Depends on
hub fetch#19 — bare clones at~/.hub/repos/<name>/must exist before worktrees can be added to them (now closed/complete)