Files
claude-plugin-nvim-agentic/skills/editor-act/SKILL.md
T
oleks acf207e53b Initial commit: nvim-agentic-companion plugin
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
2026-05-21 00:22:05 +03:00

4.7 KiB

name, description, disable-model-invocation, allowed-tools
name description disable-model-invocation allowed-tools
editor-act Drive the user's running Neovim instance — open files, run user commands, trigger keymaps, jump to LSP locations, toggle UI, evaluate small lua snippets. Uses `mcp__neovim__nvim_command` / `nvim_eval` against the live instance. Prefers the user's own commands and keymaps over teaching new vim syntax. Will *not* edit buffer contents — that work is handed off via the `claude-code-handoff` skill. Trigger on "open <file> in nvim", "jump to definition of", "show file finder", "split this", "toggle neo-tree", "run this command in my nvim", "go to next diagnostic", "save my buffer". false Bash, Read, Skill, AskUserQuestion

editor-act — do things in the user's nvim

Owner: nvim-agentic-companion:companion. This skill is for acting on the running editor in ways that do not modify buffer contents. For buffer edits, invoke claude-code-handoff instead.

Preconditions

mcp__neovim__* tools must be present. If they aren't, stop and tell the user to restart nvim + Claude Code (see editor-introspect for the recovery message).

The action hierarchy

When you need to do X, pick the lowest-impact form that works:

  1. An existing user command the user already has — :Telescope find_files, :Neotree, :Trouble, :GitSigns .... These reflect how the user already navigates and produce no surprises.
  2. A user keymap — when the user asks "open the file finder," running their <leader>ff is preferable to running :Telescope find_files directly: same result, but if they later remap it you also get the new behavior. Use vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes("<leader>ff", true, false, true), "n", false).
  3. A built-in vim command:edit, :vsplit, :tabnew, :write, :bnext — fine for navigation when no plugin command applies.
  4. Lua eval — last resort, for things with no command surface: lua vim.diagnostic.goto_next() or lua vim.lsp.buf.definition(). Keep snippets short and obvious. Never paste multi-line scripts.

Safe actions you can do without asking

  • Open a file (:edit, :vsplit, :tabnew <path>).
  • Jump to a location, definition, or reference (vim.lsp.buf.*, vim.diagnostic.goto_*).
  • Trigger a user command/keymap they already have.
  • Toggle a UI element (file tree, trouble, bufferline state).
  • Run :write if the buffer's only change is one you just made via a user-blessed command (e.g. they asked you to format and you ran :lua vim.lsp.buf.format()).

Actions that require a confirmation first

AskUserQuestion before:

  • Closing windows or buffers (:q, :bd, :tabclose, :close).
  • Writing files the user did not just ask you to write.
  • Touching files outside the current project root.
  • Changing global state: colorscheme, leader, options that affect every buffer.
  • Running anything destructive against the filesystem from inside lua (os.remove, vim.fn.delete, etc.).

Actions you do not do

  • Editing buffer contents. If the user wants code changed, that's claude-code-handoff's job. Do not type characters into a buffer via feedkeys, do not nvim_buf_set_text, do not paste into a buffer. The reason: changes should land as a diff the user can review via claudecode.nvim's accept/reject UI, not as silent mutations.
  • Quitting nvim (:qa, :wqa).
  • Source new lua / vimscript files the user didn't approve. The declarative config is the source of truth.

After each action

Leave one short trail sentence in your response: what you did, and what the user should see. Examples:

  • "Ran <leader>ff — telescope file picker is open in your nvim window."
  • "Jumped to lualine.nvim/lua/lualine/init.lua:312 via vim.lsp.buf.definition()."
  • "Opened neovim.nix in a vsplit on your right pane."

If the action didn't produce visible feedback (e.g. you only saved a buffer), say so — the user can't tell from the screen alone.

Common patterns

Open a file from a path you just produced:

:e /home/oleks/projects/servers/emmett/nixos/neovim.nix

Open at a specific line:

:e +199 /home/oleks/projects/servers/emmett/nixos/neovim.nix

Find what the user has mapped, then run their mapping:

:verbose nmap <leader>ff    " confirm what's there
" then feed the keys so their setup runs end-to-end
:lua vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes("<leader>ff", true, false, true), "n", false)

Move to next LSP diagnostic in current buffer:

:lua vim.diagnostic.goto_next()

List loaded LSP clients for the current buffer:

:lua print(vim.inspect(vim.lsp.get_clients({ bufnr = 0 })))