Most engineers who work across more than one Claude-style runtime, and there are a lot of us now, have a skills folder that started clean and ended up a sediment. Some skills got there via /plugin marketplace add from a Claude Code session that is no longer running. Others got pasted in from a tutorial. A few are forks that diverged from upstream and never came back. The version of any one skill on your machine is whatever the most recent install command happened to write. There is no source of truth, because the install path was never the source of truth, the marketplace listing was, and the marketplace listing belongs to whoever last updated it.

GitHub shipped gh skill in version 2.90.0 of the GitHub CLI on April 16, 2026. It is the source of truth.

What it does

gh skill is four subcommands. install adds a skill to a runtime. update pulls the latest from upstream and refreshes locally. publish ships your skill back to GitHub with validation against the Agent Skills spec and a repo-security pre-flight. preview reads a skill before installing it, with an explicit security note that GitHub does not verify what skills do, and that prompt-injection risk is real.

The runtime is a flag, not a separate command. gh skill install OWNER/REPO SKILL --agent claude-code writes to your Claude Code skills directory. --agent cursor, --agent codex, --agent gemini-cli, --agent antigravity all work. One CLI manages skills across every Claude-flavored runtime you have installed, plus Cursor, plus the OpenAI and Google equivalents. The pinning happens once. The runtime layer is something the CLI handles.

Why this matters more than it looks like it does

The thing the public discourse keeps missing is that skills, plugins, and agent definitions are now the actual interface to most agentic coding work. The IDE part is almost beside the point. The thing that determines what your AI partner does next is whatever skill was loaded into context, with what version, and against what scope rules. If your skills folder is sediment, your AI partner is too.

The single source of truth pattern gh skill enables, install via OWNER/REPO with explicit version pinning and validation, is the thing that makes skills behave like a dependency rather than a one-off paste. package.json for skills. The version diff happens via Git, not via whoever last updated their marketplace listing. The publish path forces validation before publication. Prompt-injection awareness is wired into the read-before-install flow.

This is the boring infrastructure that ends up mattering most. The release-day excitement was Claude Routines. The thing you should actually install this week is gh skill.

The install

brew upgrade gh
gh --version

If you see 2.90.0 or higher, you already have it. If not, the upgrade will pull it. From there:

gh skill install mvanhorn/last30days-skill --agent claude-code
gh skill update mvanhorn/last30days-skill
gh skill preview mvanhorn/last30days-skill

The same three commands work for any of the cross-runtime skills. The skill we covered separately this week, last30days-skill, was installed via this exact path.

What to test first

Audit your existing .claude/skills/ directory. The ones you can already identify by GitHub OWNER/REPO can be re-installed via gh skill so they are now version-pinned. The ones that came from a paste or a fork are the ones that should make you nervous. Move them to a quarantine subdirectory until you can either find the upstream or rewrite them as something you control.

Then pick one of your own skills, the cleanest one you have, and run gh skill publish --dry-run. The validator will tell you what the Agent Skills spec considers required vs. optional vs. underspecified. Most internal skills will fail the dry run, which is the point. The failure modes are useful. Fix them and your skill is now portable across the five runtimes the spec covers.

Why this earned the [INSTALL NOW] tag

This week's brief flagged three things at once. The CLI is allowlist-clear (official GitHub). It does not overlap anything we already have, because what we had was the per-runtime install path with no version control. The install cost is one brew upgrade plus an audit pass on your skills folder, which you should be doing anyway. The cost of skipping it is that your skills layer continues to drift while everyone else's converges on the version-pinned standard. The drift will get more expensive every week, because more public skills will assume the spec going forward.

There is no reason not to install this tonight. Run the upgrade, run the audit, pick your one cleanest skill and publish --dry-run it. The whole loop fits in twenty minutes.