Install Nix in the Claude Code web sandbox (the cloud environment) as a general-purpose package installer, then install packages from the Nix binary cache with no GitHub access. Use whenever a web session needs a tool that isn't preinstalled and isn't in a language registry (npm/pypi/crates/go) — Neovim, ripgrep, a…
Google API Improvement Proposals (AIP) reference. Use BEFORE designing or reviewing APIs, protobuf definitions, or any work involving Google API design standards. Fetches relevant AIP rules from https://google.aip.dev for the task at hand.
Analyze a git repo's history to surface high-churn files, ownership risks, bug hotspots, momentum trends, and firefighting patterns. Use this skill whenever the user wants to understand a codebase, assess repo health, or orient themselves before reading code — even if they don't explicitly say "audit". Examples…
GitHub CLI (gh) conventions and the inline PR review recipe. Use when working with GitHub repositories, PRs, issues, actions, gh api, or any GitHub operations from the command line.
This skill should be used when creating a GitHub pull request via gh pr create. Covers the gh CLI mechanics; PR title and body conventions come from the pr-style skill.
This skill should be used BEFORE running any git commit command. Triggers when about to run git commit. Ensures commit messages follow Conventional Commits specification.
Interact with the user's running Neovim instance via RPC. Use this skill when you need to execute Lua or Vimscript inside Neovim, query buffer state, send commands, or interact with the Neovim runtime in any way. Triggers when the user asks about their current Neovim session, wants to run something inside Neovim, or…
This skill should be used when creating or editing a GitHub pull request title or description, regardless of tool (gh CLI, GitHub MCP tools, API). Defines PR title format and body format with Why/What/Notes sections.
Deliberate end-to-end review pass over a completed change, applying the laziness ladder. Invoke when the user asks for a review, or when orchestrating one. Not a routine step after every edit.
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…
Conventions and tooling for authoring a Neovim plugin in Lua. Use when creating, modifying, or reviewing a plugin — plugin structure, ftplugin, health checks, setup(), vimdoc, LuaCATS, lazy loading — or when working in a directory that looks like one (plugin/, lua/, ftplugin/).
Plan work with the user in a PLAN.md, then implement it step by step, with /clear once the context fills up. Use before creating a plan, when the user mentions a PLAN.md, or when resuming work after /clear.
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: