AgentSkills CLI 1.1: skills from NuGet, npm and git, how it compares with dotnet-package-skills, and what's next

· 11 min read · dotnet nuget ai agent-skills developer-experience
AgentSkills CLI 1.1: skills from NuGet, npm and git, how it compares with dotnet-package-skills, and what's next

AgentSkills CLI 1.1.0 is out. It is a .NET tool that installs Agent Skills (the SKILL.md folders that Claude Code, Cursor, Codex and other coding agents load) from NuGet, npm, GitHub, GitLab, any git URL, well-known endpoints or a local folder, into every agent you use.

Last month the NuGet team published dotnet-package-skills, a tool that copies skills out of the NuGet packages your project references. People have asked how the two relate, so this post covers why AgentSkills CLI exists, what changed in 1.1, an honest comparison, and where 2.0 is going.

Why I built it: CritterStack AI Skills ship in a NuGet package

In May, JasperFx’s CritterStack AI Skills (guidance for Marten, Wolverine, Polecat and the rest of the Critter Stack; today well over a hundred skills) were being distributed the way .NET teams distribute everything: as a NuGet package, JasperFx.AiSkills, on JasperFx’s own feed.

The tooling for skills at the time was vercel-labs/skills (npx skills), which installs from git repos and well-known endpoints. It had no NuGet path at all, and for npm it could only sync skills out of packages already installed in node_modules (an experimental command), not fetch a package from a registry. Getting a package’s skills into .claude/skills meant downloading the .nupkg, unzipping it and copying folders by hand, then doing it again on every release, on every machine.

So I built a .NET port of npx skills with NuGet and npm as first-class sources: name a package and it is fetched from its feed or registry, the same way for both ecosystems. Underneath that, it fully supports the Agent Skills specification: any spec-compliant skill installs as-is, with its SKILL.md frontmatter, scripts, references and assets intact, and skills published through the spec’s well-known endpoints install with their SHA-256 digests verified. The timeline so far:

  1. May 23First commitA .NET port of npx skills, NuGet and npm first-class
  2. May 250.2.0First public release
  3. June 31.0.0Stable: CLI, lock format and install layout
  4. November 51.1.0Updates for every source, restore, private feeds

It reads your existing NuGet.config and .npmrc, including private feeds, scoped registries and credentials, so a private feed like JasperFx’s works the same way dotnet restore does, and a private npm registry the same way npm install does. Packages can ship skills alongside their code, a skills/ folder in a .nupkg or an npm tarball. Installing the whole CritterStack set is one command:

dotnet tool install --global agentskills-cli
agentskills-cli add JasperFx.AiSkills -y

It shares the lock file format and the .agents/skills/ directory with npx skills, so the two tools see each other’s installs.

What’s new in 1.1

1.0 could install and remove skills; keeping them current was the weak spot. update only understood GitHub sources, so a NuGet package like JasperFx.AiSkills could not be updated at all. 1.1 fixes that and a lot around it.

Updates for every source, by package. outdated reports and update installs, for NuGet and npm versions, GitHub, GitLab, any git URL, well-known endpoints and local folders. Target a whole package, pin an exact version, or stay inside a major version:

agentskills-cli outdated                            # what changed upstream
agentskills-cli update JasperFx.AiSkills -y         # every skill from that package
agentskills-cli update JasperFx.AiSkills@1.18.0 -y  # exactly that version
agentskills-cli update --version-lock major -y      # no breaking (major) versions
agentskills-cli outdated --exit-code                # CI gate: exit 1 when out of date

On a real run against the private JasperFx feed, outdated found 1.18.0 for all 126 skills from 1.17.0 in about two seconds (one version lookup for the whole package), and update moved them in about four. Reinstalls keep each skill’s scope, agents, and symlink or copy mode.

restore rebuilds a checkout from skills-lock.json, the way dotnet restore or npm ci do. --frozen fails in CI when a source no longer matches the locked hash.

Name conflicts are caught. Two packages that both ship a skill called greeter used to overwrite each other silently. Now add stops before installing anything, and you choose: install under another name with --as greeter=greeter-contoso, replace it, or skip it. The alias survives update and restore.

Private feeds just for skills. feed add and registry add keep skills feeds in .agents/nuget.config and .agents/.npmrc (committed with the repo, no secrets) and ~/.agents/... (your credentials), in the standard file formats, without touching your normal .NET or npm configuration:

agentskills-cli feed add https://pkgs.contoso.com/v3/index.json --name contoso
agentskills-cli registry add https://npm.contoso.com/ --scope @contoso --token-env CONTOSO_NPM_TOKEN

Package source mapping is honored. If your NuGet.config says JasperFx.AiSkills only comes from the JasperFx feed, that is now the only feed the tool asks. Before, every feed was tried in order, so a package with the same id on nuget.org, perhaps with a higher version number, could have been installed in its place. Skills are instructions your agent follows, so that kind of dependency confusion matters more than usual.

Fixes that mattered. The project’s own NuGet.config was ignored, NuGet credential providers (Azure Artifacts and others) were never wired up, and project-scope skills were never checked for updates. All three are fixed, along with --version and a version command that finally tells you what you are running.

The full list is in the 1.1.0 release notes.

dotnet-package-skills arrives

dotnet-package-skills was imported into the NuGet team’s Client.Tools repository on October 16, and its first beta reached nuget.org on October 26. It solves a narrower problem very carefully: after dotnet restore, skills inside your project’s packages sit in ~/.nuget/packages, outside the repo where agents look. The tool reads your project’s resolved package references and copies those skills into .agents/skills/.

It is good to see. The NuGet team shipping a tool for skills inside packages confirms the idea AgentSkills CLI was built on in May: package authors are the right people to write guidance for their libraries, and NuGet is the right way to ship it.

The two tools start from different places. dotnet-package-skills starts from the project: whatever packages it references, their skills follow. AgentSkills CLI starts from the source: you name a package, repo or feed, and it installs from there.

AgentSkills CLIdotnet-package-skills
SourcesNuGet feeds, npm, GitHub, GitLab, any git URL, well-known endpoints, local foldersNuGet packages a project references, after restore
How you choose skillsName a package or sourceAutomatic from the project’s references
NetworkDownloads what you addNone, reads ~/.nuget/packages
Where they goEvery agent’s folder (symlink or copy), project or globalOne destination folder per run (default .agents/skills)
Updatesoutdated / update against feeds and repos, version locks, --exit-codeFollows the project’s package versions
Team and CIrestore --frozen, --json outputExit codes; the manifest is the only machine-readable output
Name conflictsAlias, replace or skipSkips the colliding skills and reports an error
Status1.1.00.1.0 beta

Where dotnet-package-skills is stronger today:

  • It follows the project automatically. Upgrade a package, run it again, and the skills match the new version, with nothing to type.
  • Stale skills. It reports skills whose package left the project, and uninstall --stale removes them.
  • --dry-run, careful handling of several versions of one package, and a polished interactive picker.

Where AgentSkills CLI goes further:

  • Skills-only packages don’t have to be project dependencies. JasperFx.AiSkills is guidance, not code. dotnet-package-skills copies skills only from packages already restored into the local NuGet cache, which in practice means referencing the package from a project first. AgentSkills CLI installs it straight from the feed.
  • More than NuGet. Skills from npm, git hosts and well-known endpoints, and one tool for a team that mixes .NET with other stacks.
  • Every agent at once, and user-wide installs as well as per project.
  • Updates on your terms, restore for CI, private feeds and registries just for skills.

One package layout for both

The two tools look for skills in different places inside a package. dotnet-package-skills reads only skills/<name>/ at the package root. AgentSkills CLI originally followed the layout JasperFx.AiSkills uses, contentFiles/any/any/skills/<name>/, and as of 1.1 it reads both, preferring skills/.

That makes the advice for package authors simple: put skills in skills/<package-id>-<skill-name>/ at the package root, with the folder name and the name in SKILL.md identical. Packages laid out like that work with both tools. It is one line in your .csproj:

<ItemGroup>
  <None Include="skills/**/*" Pack="true" PackagePath="skills/%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Packages that use contentFiles, including JasperFx.AiSkills as of 1.18.0, keep working with AgentSkills CLI; dotnet-package-skills won’t find their skills until they move to skills/.

The two tools also coexist safely in one repo. Each refuses to overwrite a skill folder the other installed, so the worst case is a reported conflict rather than a lost skill. My only advice is to let one tool own each skill.

What’s next: 2.0

2.0 is about doing what dotnet-package-skills does, at least as safely, while keeping everything it doesn’t do. The main pieces:

  • sync: read the project’s resolved NuGet packages (and npm dependencies) and install their skills from the local package cache, offline, for every agent. Re-run after an upgrade and the skills follow, with skills from dropped packages reported and removable with --prune.
  • --dry-run everywhere, and coexistence with dotnet-package-skills: list will show skills it installed, and an import command will move them over.
  • Hardening: a lock against concurrent runs, refusing to write through links it doesn’t own, installs that either fully succeed or change nothing, lock files that are identical on Windows and Linux, and a doctor command for broken setups.
  • Trust: an inspect step that shows a skill’s files, scripts and allowed tools before you install it, and --require-signed for NuGet package signatures.
  • Authoring: validate to lint a skill against the spec and pack to generate the .csproj or package.json entries.
  • Teams: a skills.json manifest with version ranges next to the lock file, and a GitHub Action that opens update pull requests.

.NET 8 stays supported in 2.0, alongside .NET 10 (and .NET 11 and later through roll-forward). There is no date yet. I’d rather ship it in previews as the pieces land than hold everything for one release.

Try it

dotnet tool install --global agentskills-cli   # or: dotnet tool update --global agentskills-cli
agentskills-cli add anthropics/skills          # from GitHub
agentskills-cli add JasperFx.AiSkills          # from a NuGet feed
agentskills-cli outdated
#dotnet #nuget #ai #agent-skills #developer-experience