Claude Skills by vinta

Use when making any git commit. Always pass why the changes were made as the argument; when no reason was stated, pass the request that prompted the changes instead — never an invented why.

Use when creating or editing a skill that uses Bash commands, file writes, or external tools and the allowed-tools frontmatter may be incomplete or carry entries that grant nothing

(project) Use when editing any file under skills/ or plugins/ to bump the plugin version and check the manifests

(project) Use when updating install tasks in playbooks/roles/ against upstream docs — bumping a pinned version, adopting a newly recommended install method, repointing a doc link that moved, or realigning the community.general pin with the brew-installed ansible

Use when auditing Claude Code settings and env vars against the latest docs and suggest tailored changes

Use when about to choose, configure, or refine a tool, library, config format, API pattern, or project setup, or before proposing a design of your own — research current guidance, pitfalls, and prior art first; already knowing an approach, or assuming no prior art exists, is not an exemption. Also use when the user asks about best practices, gotchas, or recommended patterns, or says "search online"

Use when the user asks for a blindspot pass or to find their unknown unknowns, or signals unfamiliarity with a domain, tool, or codebase area ("never used X", "first time doing Y", "no idea where to start", "don't know what I don't know") before working there. Interviews the user with recon-fed questions, turning unknown unknowns into known unknowns and naming silent assumptions so they can prompt well

Use when the user asks what could be deleted or reduced to simplify a codebase, says "over-engineered", "find bloat", "YAGNI pass", or wants a repo-, folder-, or file-wide audit for over-engineering — hunts dead code, reinvented stdlib, needless dependencies, and single-implementation abstractions, reports ranked cuts, applies only the picks. Not a diff review and not a bug hunt

Use when refactoring a user-level or project-level AGENTS.md for progressive disclosure

Use when refactoring a user-level or project-level CLAUDE.md for progressive disclosure

Use when you want docs, issues, READMEs, comments, or UI text written in Global English — plain words, translation-friendly grammar, still native-sounding

Use when writing English prose the user will sign — READMEs, blog posts, docs, code comments, issues, PRs, PR and issue comments, emails — drafted or rewritten in their own voice at native fluency. Fires mid-task too: a comment drafted inside another skill's workflow, or text the user will approve before it ships

Use when about to refactor or refine an existing skill, its SKILL.md or sibling files, from a full restructure down to a one-line wording fix; a change that looks too small to need this skill is not an exemption. Not for creating a skill from scratch or for fixing only its allowed-tools