oleks
acf207e53b
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
126 lines
4.7 KiB
Markdown
126 lines
4.7 KiB
Markdown
---
|
|
name: editor-act
|
|
description: |
|
|
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".
|
|
disable-model-invocation: false
|
|
allowed-tools: 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 })))
|
|
```
|