| name | vibing-worktree |
| description | Create, list, attach to, and finish git-worktree-backed isolated work areas for vibing.nvim chats, entirely via natural language — no separate UI. Use when the user wants to isolate work in its own worktree ("split this into its own worktree", "start this in isolation"), wants to see what worktrees/branches exist ("what worktrees do I have", "what's in progress"), wants to switch/attach the current or a new chat to an existing worktree ("let's go into the auth-fix worktree", "attach to worktree X"), or wants to clean one up when done ("clean up this worktree", "I'm done with this branch's worktree"). |
vibing-worktree
Git worktrees provide isolated working directories for parallel development. This skill uses
plain git commands and this chat's own frontmatter — no bespoke helper script, no metadata
file. A worktree's existence on disk is its entire state.
Directory convention
Worktrees created for isolated work go under .vibing/worktrees/<branch-name>/ at the git
root — flat, one worktree per directory, nothing else stored alongside it. This convention is
also stated in every vibing.nvim chat's system prompt; follow it so git worktree list stays
predictable for later listing.
List — "what worktrees exist?"
git worktree list --porcelain
For a one-line hint of what was last done on a given worktree's branch:
git log -1 --format=%s <branch>
This shows every worktree registered against the repo, not just ones under
.vibing/worktrees/ — including ones created outside vibing.nvim entirely (a bare
git worktree add, or claude --worktree run directly in a terminal). Present branch, path,
and (if you fetched it) the last commit message so the user can pick one, whether they're asking
out of curiosity or as a lead-in to attaching.
Create — "split this off into its own worktree"
-
Derive a short, English, lowercase, kebab-case branch name from the task being discussed
(e.g. "認証セッションのバグを直したい" → fix-auth-session-bug). Confirm it with the user if
the mapping isn't obvious — a wrong name is annoying to rename later.
-
Create the worktree:
git worktree add -b <branch> .vibing/worktrees/<branch>
If this fails (branch already checked out elsewhere, etc.), the error is self-explanatory —
surface it verbatim rather than retrying blindly with a different name.
-
Find this chat's own file path. The system prompt contains a line like
Current vibing.nvim chat buffer file: /path/to/chat.md — use that path directly. It is
injected per-request by vibing.nvim and is always accurate even when multiple chat buffers
are open. Avoid calling mcp__vibing-nvim__nvim_get_info for this purpose; it returns
whichever buffer currently has focus in Neovim and may return the wrong one.
-
Edit that chat's frontmatter through the live Neovim buffer, not the file on disk — a brand-new
chat (first exchange in a freshly opened buffer) has no file on disk yet, so Read/Edit
against the path will simply fail or find nothing. Use the vibing-nvim MCP tools instead,
which operate on buffer content regardless of save state:
- Call
nvim_list_buffers and match name against the chat buffer path from the system
prompt to get its bufnr. Don't assume bufnr: 0 (current buffer) — the chat buffer may
not have focus.
- Call
nvim_get_buffer({ bufnr }) to read the current content.
- Set
working_dir: .vibing/worktrees/<branch> (relative to the git root) in the frontmatter
block, then call nvim_set_buffer({ bufnr, lines }) with the full updated content.
Don't open a new chat buffer — the current conversation continues, and its next turn already
runs in the new worktree.
-
If the vibing-nvim MCP connection isn't available at all, tell the user the worktree is
ready at .vibing/worktrees/<branch> and that they'll need to set working_dir in the chat's
frontmatter by hand (or open a new chat there) to actually start using it.
Attach — "what worktrees are there? — let's go into the auth one"
Works the same whether this is a brand-new chat's first exchange or mid-conversation in an
existing one.
- Run the List steps above to surface candidates.
- Once the user picks one, follow Create steps 3-5 to point this chat's own
working_dir
frontmatter at the chosen worktree's path — the worktree already exists, so skip the
git worktree add step (step 2).
Finish — "clean up this worktree"
git worktree remove <path>
Never add --force. If git refuses because of uncommitted changes, that's it protecting the
user from losing work — report the exact error and let them decide whether to commit, stash, or
discard those changes themselves, rather than retrying with --force on their behalf.
If the removed path was this chat's own working_dir, clear that frontmatter field once removal
succeeds (reverting to the main repo root) — leaving it pointed at a now-deleted directory would
break the next turn.