Delivering agent skills in NuGet packages
The .NET team has been experimenting with shipping agent skills inside NuGet packages: SKILL.md files travel with the package and land on disk through dotnet restore, so an agent reads documentation for the exact version in use. Richard Lander reports that frontier models already reverse-engineer metadata well, that the win is mostly efficiency, and that markdown inside packages adds a new threat vector.
Key points
- Skills travel inside the package: a skills/ folder of SKILL.md files using the same YAML header as the agentskills.io format.
- dotnet restore already pulls them down, and project.assets.json shows which packages in a graph ship skills.
- dotnet-inspect package <id> -S Skills or project <csproj> -S Skills lists skill paths and contents for an agent's context.
- dotnet-package-skills install copies skills from direct dependencies into .agents/skills for committing; keeping them in sync with PackageReference bumps is on you.
- Evaluate with frontier models: one skill set ships to every model, so a win on a cheap model can be a loss on an expensive one.
- NuGet MCP is not updated for skills yet; the team says that work is coming.
NuGet packages can now carry agent skills. A package can ship a skills/ folder of SKILL.md files — markdown with a YAML header holding name and description — and dotnet restore drops them on disk next to the binaries, so an agent reading the package cache sees documentation that matches the exact version in use, including APIs published minutes ago. project.assets.json lists which packages in a graph bring skills.
Richard Lander's team built two helpers around the idea: dotnet-inspect lists the skills of a package or project with -S Skills and can print them straight into an agent's context, while dotnet-package-skills install copies them into .agents/skills so they can be committed to the repo. Their findings: frontier models already reverse-engineer assembly metadata well, so gains land mostly in efficiency; one skill set serves every model, so test with frontier models, not only cheap ones.
Real-world use
- A library vendor shipping version-matched usage guidance with every release so agents stop guessing at APIs added after the model's training cutoff.
- A team standardising how agents write tests by committing skills copied from packages such as Mockly into .agents/skills.
- An agent answering questions about a project's package graph by reading skill files from the NuGet cache instead of decompiling assemblies.
- A CI check that scans project.assets.json for packages with skills and flags stale committed copies.
Why it matters
Version-matched skills cut the tokens an agent burns reverse-engineering a library and reduce wrong API guesses on packages the model has never seen — but only when those skills are evaluated and come from a maintainer you trust.