publish-plugins
(project) Use when editing any file under skills/ or plugins/ to bump the plugin version and check the manifests
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
$ npx -y skills add vinta/hal-9000 --skill best-practices --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/best-practicesContext preview
The summary Claude sees to decide when to auto-load this skill.
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
name: best-practices description: 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 argument-hint: "[tool, library, pattern, or design to research]" allowed-tools: - WebSearch - WebFetch - Bash(ctx7:*) - Bash(npx ctx7:*) - Bash(npx ctx7@latest:*)
Answer two questions from current sources: **what's the recommended way**, and **what bites people** (the gotchas and pitfalls around it). A how-to without its pitfalls is half an answer.
The user's argument may be a question or an imperative. Imperatives ("refine X", "set up Y") determine what Phase 2 does, not whether Phase 1 happens. Phase 1 always runs.
1. Break the topic into 2-4 specific queries. Dedicate at least one query to pitfalls ("common mistakes with X", "X gotchas in production"): pitfalls live in issue threads, migration guides, and post-mortems, not in getting-started docs. Dedicate one query to how leading open source projects or production teams do it, which can differ from what the docs recommend. For single-library lookups, call `find-docs` or web search directly without subagents. 2. Dispatch one subagent per query in a single message: in Claude Code, pass `model: sonnet` on each Agent call; in Codex, spawn them in one request, selecting a faster, lower-cost model in each spawn. Tell each subagent to use `find-docs` and web search, and to report in under 400 words: the recommended approach, concrete code/config examples, and every pitfall it found with its consequence, including minor or uncertain ones (its job is coverage; you rank and filter), with each claim citing its source and publication date. 3. Present the recommended approach, key patterns, and gotchas covering every recommendation (not just the primary one), each claim keeping its source citation.
Opinionated AI coding agent and dev environment automation for macOS that dominates your dev setup like cats rule the Internet. This project is named after Arthur C.
(project) Use when editing any file under skills/ or plugins/ to bump the plugin version and check the manifests
(project) Use when upgrading install tasks in playbooks/roles/ against upstream docs — bumping a pinned version, adopting a newly…
Use when auditing Claude Code or Codex settings and env vars against the latest docs to suggest tailored changes
Use when the user asks for a blindspot pass or to find their unknown unknowns, or signals unfamiliarity with a domain, tool, or…
Use when making any git commit. Pass the failure, false claim, or risk the changes fix as the argument; for an addition or a…
Compare A vs B, weigh pros and cons of A, B, C, ..., or explain the nuance between sentences — a quick answer from what the model…