dotfiles

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.

This skill should be used when creating a GitHub pull request via `gh pr create`. Defines PR body format with Why/What/Notes sections and ensures proper assignment.

This skill should be used when creating a GitHub pull request via `gh pr create`. Defines PR body format with Why/What/Notes sections, ensures proper assignment, and prompts for Jira ticket number.

Find, navigate, read, and edit notes in the user's personal Obsidian vault (an iCloud-synced markdown collection on macOS). Use whenever the user mentions "the vault", "my notes", "Obsidian", a daily note, a meeting note, scratchpad, or asks to look up/jot down something that sounds personal-knowledge-base-like (e.g. "what did I write about X", "add a note about Y", "today's daily note") — even if they don't say the word "Obsidian".

Find, navigate, read, and edit notes in the user's personal Obsidian vault (an iCloud-synced markdown collection on macOS). Use whenever the user mentions "the vault", "my notes", "Obsidian", a daily note, a meeting note, scratchpad, or asks to look up/jot down something that sounds personal-knowledge-base-like (e.g. "what did I write about X", "add a note about Y", "today's daily note") — even if they don't say the word "Obsidian".

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".

Guide for writing Neovim plugins in Lua following official Neovim conventions (https://neovim.io/doc/user/lua-plugin/). Use this skill whenever the user is creating, modifying, or reviewing a Neovim plugin — including when they mention plugin structure, ftplugin, health checks, keymaps, setup() functions, vimdoc, LuaCATS annotations, or lazy loading in the context of Neovim plugin development. Also trigger when the user is working in a directory that looks like a Neovim plugin (contains plugin/, lua/, ftplugin/ subdirectories).

Before creating a plan, interview the user

Provide proof to your claim(s)

When done with implementation, perform self-review of the work

Capture this session's repeatable process into a reusable skill. Call at end of a process you want to automate.

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.

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 and prompts for Jira ticket number.

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 when you need to inspect Neovim state (buffers, windows, options, LSP, etc.). Also use when running inside a Neovim terminal and needing to communicate with the parent editor.

GitHub CLI (gh) command reference. Use when working with GitHub repositories, PRs, issues, actions, `gh api`, or any GitHub operations from the command line.

Use this skill BEFORE writing or editing any Go (.go) files. Triggers when about to create, modify, or add code to .go files. Enforces happy path coding, error wrapping, sentinel errors, godoc-style comments, and `go doc` usage.

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.