Adds a Claude Code agent and three skills for collaborating with the user's running Neovim instance via mcp-neovim-server and the official coder/claudecode.nvim plugin: - agents/companion.md — the nvim companion identity, prefers runtime introspection over training-data guessing - skills/editor-introspect — read-only queries against the live editor - skills/editor-act — safe driving (open, jump, toggle, run); no buffer edits - skills/claude-code-handoff — delegate buffer edits to the in-editor Claude Code session so users get a diff to accept or reject
4.8 KiB
name, description, disable-model-invocation, allowed-tools
| name | description | disable-model-invocation | allowed-tools |
|---|---|---|---|
| claude-code-handoff | Delegate buffer-editing work to the in-editor Claude Code session managed by `coder/claudecode.nvim`. Use whenever a request would *change code in a buffer*: refactor, generate, explain-and-edit, fix a diagnostic. Opens (or focuses) the Claude Code split, attaches the relevant buffer/selection, sends an instruction, and tells the user how to accept/reject the resulting diff. Avoids duplicating Claude Code's diff UX from outside the editor. Trigger on "refactor this", "fix this in nvim", "generate the function in this buffer", "have Claude edit my file", "send this to Claude in nvim", "let Claude in the editor handle it". | false | Bash, Read, Skill, AskUserQuestion |
claude-code-handoff — let the in-editor Claude do the editing
Owner: nvim-agentic-companion:companion. This skill is the bridge
between you (the outer Claude Code session) and the inner
Claude Code session running in the user's nvim via
coder/claudecode.nvim. The inner session has the buffer, selection,
diagnostics, project root, and the diff-accept/reject UI. It is the
right tool for any edit that the user should review before it lands.
When this skill fires
- The user wants buffer contents modified: refactor, rename, fix, generate, complete, restructure.
- The change is bigger than a one-line vim substitute the user could do themselves.
- The user wants a diff to look at before committing.
When this skill does not fire
- Pure navigation (
editor-act). - Pure questions about state (
editor-introspect). - Edits to config files via the declarative NixVim path (those are
yours to edit with the
Edittool, then runnix run .#deploy).
The configured keymaps (current NixVim setup)
These are defined under <leader>a* in
/home/oleks/projects/servers/emmett/nixos/neovim.nix:
| Mode | Keys | Command | Purpose |
|---|---|---|---|
| n | <leader>ac |
:ClaudeCode |
Toggle the Claude Code split |
| n | <leader>af |
:ClaudeCodeFocus |
Move cursor to the split |
| n | <leader>ar |
:ClaudeCode --resume |
Resume previous session |
| n | <leader>aC |
:ClaudeCode --continue |
Continue last session |
| n | <leader>ab |
:ClaudeCodeAdd % |
Add current buffer to context |
| v | <leader>as |
:ClaudeCodeSend |
Send visual selection |
| n | <leader>aa |
:ClaudeCodeDiffAccept |
Accept the proposed diff |
| n | <leader>ad |
:ClaudeCodeDiffDeny |
Reject the proposed diff |
If the user remaps these, re-introspect via editor-introspect before
quoting them.
Handoff procedure
-
Confirm the split is open. Either ask
editor-introspectto check for a Claude Code buffer/window, or just run:ClaudeCodeviamcp__neovim__nvim_command— the command is idempotent (toggles, but if already visible the user sees no surprise). -
Attach the right context.
- If a buffer-level change:
:ClaudeCodeAdd %(current buffer) or:ClaudeCodeAdd <path>(a specific file). - If a selection-level change: the user must have a visual
selection. If they don't, ask them to make one, or offer
editor-actto highlight the relevant range first.
- If a buffer-level change:
-
Send the instruction. Phrase it as the user would speak to an agent that already has the file open. Example: instead of "in neovim.nix add a keymap for ...", say "add a
<leader>twkeymap that toggles wrap, next to the existing wrap-toggle block." Send via:ClaudeCodeSend(after selection) or by typing the prompt into the Claude Code buffer (mcp__neovim__nvim_commandplus an explicit feedkeys is overkill — usually the user can type it themselves once focus is in the split). -
Brief the user. One sentence: where the conversation is happening (the split), what to expect (a proposed diff), and the accept/reject keys. Example:
Sent to the Claude Code split. You'll see a proposed diff —
<leader>aato accept,<leader>adto reject. -
Stop. Don't try to mirror or predict the inner session's output. The user will come back with the result, and you can resume from there.
Avoiding double-work
If the user is already inside the Claude Code split typing to the inner session, do not also try to do the edit yourself. Either:
- Stay quiet on the editing question and only handle introspection / navigation side requests, or
- Acknowledge: "the inner Claude is on it — ping me back if it stalls or you want a second opinion."
The whole point of the handoff is to avoid two agents editing the same buffer with different mental models.