Delivering Skills in NuGet packages - .NET Blog

Agent skills were introduced by Anthropic in 2025 and have quickly become commonplace for AI-driven development. dotnet/skills and Impeccable skills are good examples. Agent skills are typically distributed via git repos. We’ve been working on skill delivery via NuGet packages and found that the approach can be effective. The common thread is that repos and packages are units of development that can be used as distribution vehicles for skills.
Skills solve two main problems: fill in gaps in model knowledge and can prescribe “our way” of approaching a task. New NuGet packages will always be ahead of model training and can benefit from just-in-time skill delivery.
Here’s a quick demo using the markout package, whch contains a set of skills:
We’ve done a lot of experimentation. We’ve found that agents (as a baseline behavior) are capable of finding content in the NuGet cache to learn about a package. This includes reading README.md files and even writing throwaway programs that reflect over assembly metadata. Agents using frontier models are impressively creative and can derive surpising insight, although not necessarily cheaply.
The fundamental question is whether they apply that creativity and capability to reverse-engineering documentation from metadata or working on your actual business problem. We sometimes say “why not both?”. It’s tough when you’re usage has to fit within a monthly token budget.
This is the problem we set out to solve.
Skills are markdown files with a YAML header, named SKILL.md. agentskills.io is the official spec site for the format. NuGet-delivered skills use the same format.
The following example skill can be used to direct agents to run vulnerability checks on project dependencies.
Skills are distributed via git repos, in one of two ways.
The most common approach is to include skills in a typical “code” repo. This approach is a great starting point since everyone working on the repo gets the same experience. Skill composition changes with a PR workflow that the team can review or even revert. The dotnet/runtime repo uses this approach. It is a great experience working on that repo and seeing a variety of skills automatically used by Copilot depending on prompts.
The other primary approach is skill marketplace repos, such as dotnet/skills. These repos advertise their skills via marketplace.json. Users install the marketplace via /plugin marketplace add dotnet/skills (or similar). add is just a wrapper on git clone. That means a skill marketplace repo should be small.
The advantage of putting skills directly in your repo is that the skills are always there. A good example is using the Copilot Web Agent. Locally installed marketplace skills don’t exist off of your machine unless you take the extra step of committing them to your repo. Neither is better or worse, just different options.
NuGet packages present a challenge and opportunity for agents. The challenge is that a new package version with new APIs published five minutes ago isn’t part of the model. The opportunity is that updated skills can be co-located with updated binaries. That means that every version of a NuGet package can have perfectly-tailored skills for their use. It’s very similar to package-resident README.md files, which are intended for a different purpose and consumer.
The challenge isn’t limited to packages published in the last five minutes. Package registries also have a very long tail. It’s quite likely models know nothing substantive about most packages.
dotnet restore already pulls packages to your machine to acquire libraries. That means that package-resident SKILL.md files will be on your machine as well.
You can see markout package skills on my machine.
That’s a pretty good start and quite workable for agents. Package skills are listed in project.assets.json making it easy to determine if there are any skills available in a given package graph. However, we wanted to offer better UX than that.
We’ve been working on a few tools for discovering SKILL.md files.
The following are example workflows with dotnet-inspect:
Requesting skills in a package graph:
It can also accept a project file as input:
The intended UX with dotnet-inspect is that an agent can determine the set of skills available via a project file or directly from the registry. The agent can print those directly to its context or to a file. The file can then be searched or even stored in the repo.
dotnet-package-skills is another tool that is focused on storing skills in a repo.
This is an easy way to add skills into your repo and to ensure that they are always available. It is up to you to ensure that the skills stay up to date as matching PackageRef entries are udpated. It might be useful to write a skill to do both at the same time.
NuGet MCP is a useful tool for giving agents a deep and broad undertanding of NuGet, both for your local project and of your registry. It hasn’t yet been updated for skills. That’s a project we intend to take on soon.
Package-delivered skills are not a special kind of skill. As already stated, skills can already be delivered in multiple ways. Packages are a variation on a theme using the same format. That means that conventional skill eval applies.
Agent skills can be boiled down to delivering two benefits: efficacy (ability to deliver right answers) and efficiency (deliver answers cheaply). That doesn’t mean that agent skills always deliver efficacy and efficiency benefits. They can deliver those benefits. They can also deliver the opposite if they are badly written or tested.
The challenge with models is that cost is a major factor. If I include a SKILL.md in my package and your agent costs increase, that’s bad. That means that maintainers need to perform skill eval. Maintainers should improve or remove skills that their users report as ineffective or costly.
With frontier models, we didn’t find much room to improve efficacy, due to creative capability. With weaker models, we observed signific