I've been using SKILL.md files in my local Claude Code setup for months. Custom instructions for different tasks, each living in its own folder, each teaching the agent how to behave for a specific workflow. Works well. The annoying part has always been distribution — if I want to reuse a skill on another machine, I'm copying files manually like it's 2012.
GitHub apparently had the same frustration. Last week they shipped gh skill, a new GitHub CLI command that does for agent skills what npm did for packages.
What Even Are Agent Skills
Skills are SKILL.md files — folders of instructions, scripts, and resources that tell an AI agent how to handle a specific task. Write a documentation page. Run a specific test pattern. Format output a certain way.
They follow the open Agent Skills spec at agentskills.io and work across GitHub Copilot, Claude Code, Cursor, Codex, and Gemini CLI. The skill doesn't know or care which agent loads it.
What Shipped
Requires GitHub CLI v2.90.0 or later.
Install a skill:
gh skill install github/awesome-copilot documentation-writer
Target a specific agent and scope:
gh skill install github/awesome-copilot documentation-writer --agent claude-code --scope user
Skills go to the correct directory for your agent host automatically. No manual path work.
Pin to a version:
gh skill install github/awesome-copilot documentation-writer --pin v1.2.0
# Or pin to a commit for full reproducibility
gh skill install github/awesome-copilot documentation-writer --pin abc123def
Pinned skills get skipped during gh skill update --all, so upgrades are deliberate.
Check for updates:
gh skill update # interactive
gh skill update --all # everything at once
Validate and publish your own:
gh skill publish # validate against agentskills.io spec
gh skill publish --fix # auto-fix metadata issues
The Supply Chain Part
This is less flashy but it's the part that actually matters.
Agent skills are instructions. Instructions that shape what an AI agent does inside your codebase. A silently modified skill is a real attack surface — same as a tampered npm package, just newer.
gh skill handles this with a few concrete mechanisms:
When you install a skill, it writes provenance metadata directly into the SKILL.md frontmatter — source repo, ref, and git tree SHA. On every gh skill update call, local SHAs get compared against remote. It detects actual content changes, not just version bumps.
Publishers can enable immutable releases, meaning release content can't be altered after publication — even by repo admins. If you pin to a tag from an immutable release, you're fully protected even if the repo gets compromised later.
The provenance data lives inside the skill file itself, so it travels with the skill when it gets moved, copied, or reorganized.
Why This Is a Bigger Deal Than It Looks
The SKILL.md pattern has been spreading quietly for months. Anthropic has a reference skills repo. GitHub's awesome-copilot has a growing community collection. VS Code ships skill support. Claude Code loads them automatically.
What was missing was tooling. Right now, sharing a skill means sending a file. Updating a skill means remembering where you put it. There's no dependency graph, no version history, no integrity check.
gh skill is the package manager layer the ecosystem needed. It's early — the spec is still young, the community repo is still small — but the primitives are solid. Git tags for versioning. SHAs for integrity. Frontmatter for portable provenance.
If you maintain skills for your team or your own agent setup, the publish workflow is worth looking at now, before the ecosystem gets crowded.
gh extension upgrade --all # make sure you're on v2.90.0+
gh skill install github/awesome-copilot documentation-writer
Building content around MCP and agentic AI? I write about this stuff weekly Here !!!
Top comments (4)
gh skillas a distribution mechanism for agent skills is a smart move — it leverages existing trust signals (GitHub stars, contributor history, security advisories) instead of asking the world to learn a new registry. One thing I'd love to see: a manifest schema that declares the tools/permissions a skill needs upfront, similar to npm'senginesfield, so consumers can audit before install. Otherwise we're going to repeat the npm typosquatting story but with skills that have shell access.Thanks Sir!
Glad you liked it and loved your insights!!!
The provenance metadata living inside the SKILL.md frontmatter is the detail that makes this feel real rather than just convenient. It's easy to build a package manager that fetches files. It's harder to build one where the integrity check travels with the artifact itself, independent of any central registry.
What that enables is the skill remaining verifiable even after it's been copied, forked, or passed around outside the original distribution channel. You can email a SKILL.md to a colleague, and if they have the tooling, they can still verify where it came from and whether it's been tampered with. That's not how npm works. That's not how most package managers work. It's a quiet design choice that bets on decentralization.
The attack surface you mentioned is real, and I think it's actually larger than people realize. A compromised skill isn't just running arbitrary code—it's shaping the agent's reasoning. It can subtly steer decisions in ways that are hard to audit after the fact. "Always prefer this library." "Skip validation in this case." "Trust this external service." Those instructions look like helpful guidance. They're also perfect vectors for supply chain influence that doesn't leave an obvious executable footprint.
The pinning and immutability features feel like the right foundation, but I wonder about the social layer. If a popular skill repo gets compromised and the maintainer doesn't notice for a week, how does the ecosystem learn about it? Is there a revocation mechanism, or does the decentralized model mean each user is responsible for their own trust decisions? Feels like the kind of problem that only becomes visible after the first incident.
Thanks Sir !
Loved your Insights!!!