Skip to content

Why AgentSkills CLI

If you write .NET code and use Claude Code, Cursor, Codex, or any agent that reads the universal .agents/skills/ directory, you want a CLI that feels native: installs from NuGet, respects your NuGet.config, ships through dnx. AgentSkills CLI exists because that CLI didn't exist.

The short version

  • Install agent skills the way .NET devs install everything else - from NuGet (public or private), with your existing credentials and feeds. No new auth surface, no JavaScript runtime, no second package manager.
  • Skills can ship inside the libraries they describe. A Contoso.SampleLib NuGet package can carry the agent guidance for using Contoso.SampleLib. Users who install your library get the skills automatically; the SDK and its agent docs version together, distribute together, stay in sync.
  • First-class npm too - because TypeScript skills shipped on npm are still the bulk of the ecosystem, and AgentSkills CLI is the only tool that does proper registry fetch with .npmrc scoped-registry support (not just node_modules sync).
  • Install once and forget - dotnet tool install -g agentskills-cli and you're done; daily commands are short (agentskills-cli add ..., or one-character via a shell alias). CI runners that don't want a global install can use dnx agentskills-cli instead - same package, no install step on .NET 10+.

The bigger insight: skills inside libraries

The standard pattern for AI-agent guidance today is separate. Library X exists; some helpful third party writes "how to use library X with Claude Code" skills and publishes them somewhere else. Drift is inevitable - X ships v2 with breaking changes, the skills still describe v1 behavior, agents make broken suggestions.

When skills live inside the library package:

  • One source of truth - the skills version-lock with the SDK. v2 of the package ships v2 of the skills.
  • Zero discovery friction - users searching for the library on nuget.org or npmjs.org get the skills for free. No "you should also install MyLib.Skills" footnote in the README.
  • Standard publishing pipeline - dotnet pack or npm publish. Nothing new to learn.
  • Agent reach - any agent that reads the universal .agents/skills/ directory picks up the guidance once the user installs.

The dedicated skills-only package is still a fine option when there's no library to co-ship with. But "drop a skills/ folder into the package you already publish" is a meaningfully better default.

How to ship skills inside your library →

How it compares to npx skills

AgentSkills CLI is a faithful .NET-native port of vercel-labs/skills that adds first-class NuGet and npm support plus ergonomics. The highlights:

AgentSkills CLInpx skills
NuGet packages as a first-class sourceyesno NuGet path
npm registry fetch (not just node_modules sync)yesonly experimental_sync
Skills can ship inside library packagesyesn/a (no NuGet); npm only via experimental sync
--path across every source (NuGet, npm, git, local)yesonly /tree/<ref>/<path> for GitHub
Version-aware target matching on list / removeyesno concept of pinned matching
DI extension points for custom sources + search backendsyesprocedural, no public extension contract
Runtime.NET 8 LTS + .NET 10 from one .nupkgNode 18+

Full feature matrix →

Lock-file interop, not lock-in

By design, AgentSkills CLI writes to the same ~/.agents/.skill-lock.json and ./skills-lock.json files that npx skills uses. A skill installed by either tool is visible to the other. You can switch tools without losing tracked state, you can use both on the same machine, and a polyglot team can have npx skills users and agentskills-cli users in the same repo with no friction.

Built on the open spec

The SKILL.md format and the well-known discovery endpoint follow the open Agent Skills specification. Skills published for npx skills, the broader ecosystem, or any other spec-compliant client work here too. AgentSkills CLI implements the spec; it doesn't fork it.

Next

Released under the MIT License.