aip
Google API Improvement Proposals (AIP) reference. Use BEFORE designing or reviewing APIs, protobuf definitions, or any work…
Native Neovim config idioms and conventions — use whenever writing, reviewing, or modifying any Neovim configuration that uses Neovim's built-in conventions WITHOUT a plugin manager framework (no lazy.nvim, packer, etc.). Covers directory structure, vim.pack plugin management,
$ npx -y skills add fredrikaverpil/dotfiles --skill nvim-config --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/nvim-configContext preview
The summary Claude sees to decide when to auto-load this skill.
Native Neovim config idioms and conventions — use whenever writing, reviewing, or modifying any Neovim configuration that uses Neovim's built-in conventions WITHOUT a plugin manager framework (no lazy.nvim, packer, etc.). Covers directory structure, vim.pack plugin management,
name: nvim-config description: > Native Neovim config idioms and conventions — use whenever writing, reviewing, or modifying any Neovim configuration that uses Neovim's built-in conventions WITHOUT a plugin manager framework (no lazy.nvim, packer, etc.). Covers directory structure, vim.pack plugin management, lsp/ auto-discovery, plugin/ loading order, keymaps, and standard paths. Trigger on any task involving init.lua, plugin/*.lua, lsp/*.lua, vim.pack.add(), vim.lsp.enable(), or "native neovim config" — even if the user just says "add a plugin" or "configure LSP" in a native-style config.
Conventions for Neovim configs built on `vim.pack`, `lsp/` and `plugin/` with no plugin manager framework. Requires Neovim >= v0.12.0.
References — read the one the task needs:
| File | Covers | | -------------------------------- | ---------------------------------------------------------------------------------------------- | | `references/loading-patterns.md` | `vim.pack.add`'s `load` option, the three loading patterns, build hooks, profiling | | `references/plugin-files.md` | File skeleton per pattern, `_G.Config` sharing, `do/end` blocks, ftplugin, option interfaces | | `references/startup.md` | `:h initialization` step table, runtime directories, `after/`, exrc, help tags, standard paths |
The native config lives at **`~/.dotfiles/stow/shared/.config/nvim-fredrik/`** inside the dotfiles repo. `stow.sh` links it into place as a whole directory, so new files show up without a restow:
~/.dotfiles/stow/shared/.config/nvim-fredrik/ <- actual files (edit here) ~/.config/nvim-fredrik -> ~/.dotfiles/stow/shared/.config/nvim-fredrik
Launch it with `NVIM_APPNAME=nvim-fredrik nvim`. Neovim itself comes from nixpkgs-unstable via home-manager (`nix/shared/home/common.nix`) -- binary at `~/.nix-profile/bin/nvim`.
No framework -- each directory has a single responsibility:
| Layer | Directory | Role | | ------------------- | ----------------- | ---------------------------------------------------------------------------------------- | | **options** | `lua/options.lua` | All `vim.opt` settings, required from `init.lua` | | **utility** | `lua/` | Shared Lua modules: `lazyload.lua`, `merge.lua`, `fold.lua`, `toggle.lua`, pickers, etc. | | **plugins** | `plugin/` | Self-contained plugin files: install + setup + keymaps | | **lang plugins** | `plugin/lang/` | Per-language plugin installs, custom filetypes, autocmds, and setup | | **editor settings** | `ftplugin/` | Per-filetype `vim.opt_local` (indent, wrap, conceal) | | **server config** | `after/lsp/` | All LSP server config tables (in after/ to override package defaults) |
~/.config/nvim-fredrik/
init.lua -- leader keys, require("options"), diagnostics, keymaps
lua/
lazyload.lua -- VimEnter/UIEnter deferred setup queues
merge.lua -- deep merge helper (appends+deduplicates lists, recurses dicts)
options.lua -- all vim.opt settings
dev.lua -- local dev plugin loader
... -- other utility modules (fold, toggle, pickers, icons, etc.)
lsp/ -- (unused; nvim-lspconfig provides base configs)
parser/ -- treesitter parser .so files (managed by nvim-treesitter)
colors/ -- custom colorschemes (loaded by :colorscheme)
snippets/ -- custom snippet files (loaded by blink.cmp)
ftplugin/ -- per-filetype editor settings (vim.opt_local)
plugin/
lang/ -- per-language plugins, custom filetypes, autocmds
blink.lua -- completion (VimEnter)
conform.lua -- formatting (VimEnter)
dap.lua -- debugging (deferred to first use)
lint.lua -- linting (VimEnter)
lsp.lua -- LSP enable + LspAttach keymaps (VimEnter)
lualine.lua -- statusline (VimEnter, sync)
neotest.lua -- testing (deferred to first use)
<name>.lua -- other feature plugins (snacks, treesitter, oil, etc.)
after/
lsp/ -- all LSP server configs (overrides package defaults)
queries/<lang>/ -- treesitter query extensions (injections.scm, etc.)
syntax/<ft>.vim -- legacy syntax overrides/extensionsNotes on the layers:
opts?)` for queuing setup functions. Default is async (via `vim.schedule()`); `{ sync = true }` runs synchronously. Also provides `on_override(fn)` for project-local overrides (runs after all VimEnter callbacks). Only lualine uses `{ sync = true }`.
dicts, overwrites scalars. `vim.NIL` as a value removes a key.
falls back to `vim.pack.add()`.
Sourced alphabetically at step 11; subdirectories included via the `**` glob.
genuinely language-specific wiring: plugins, custom filetypes (`vim.filetype.add`), build hooks, autocmds. Tool config (servers, formatters, linters) lives inline in the core plugin files; per-filetype editor settings live in `ftplugin/`.
vim.pack.add({
"httpsPersonal dotfiles, managed in three layers: Nix (nix/): system configuration and packages, pinned by flake.lock and applied with a rebuild. Fully reproducible. Stow (stow/): dotfiles symlinked into $HOME with GNU Stow (not Nix).
Google API Improvement Proposals (AIP) reference. Use BEFORE designing or reviewing APIs, protobuf definitions, or any work…
Analyze a git repo's history to surface high-churn files, ownership risks, bug hotspots, momentum trends, and firefighting…
GitHub CLI (gh) conventions and the inline PR review recipe. Use when working with GitHub repositories, PRs, issues, actions, `gh…
This skill should be used when creating a GitHub pull request via `gh pr create`. Covers the gh CLI mechanics; PR title and body…
This skill should be used BEFORE running any git commit command. Triggers when about to run `git commit`. Ensures commit messages…
Where this author deviates from, or tightens, idiomatic Go defaults.