AI Agent Skills in NuGet Packages: .NET Tools, Token Costs and Security Risks

What a "skill" is​

An agent skill is a folder with a required SKILL.md file. The file has YAML metadata (at minimum a name and a description) followed by Markdown instructions. At its core, a skill is a folder containing a SKILL.md file, with metadata and instructions that tell an agent how to perform a specific task. Agents load skills through progressive disclosure: when a task matches a skill's description, the agent reads the full instructions into context. That keeps the context footprint small until a skill is needed.

The format was created by Anthropic in 2025. It has been released as an open standard and adopted by a growing number of agent products. Lander notes that NuGet-delivered skills use exactly this format. They are not a special variant.

Skills mainly do two jobs, according to the post:

• They fill gaps in what a model knows. A package published five minutes ago, or an obscure one from the long tail of the registry, won't be in training data.
• They prescribe "our way" of doing a task, as the maintainer sees it.

Why NuGet is a natural carrier​

The post describes two conventional routes, both based on git:

• Skills in the code repo. Everyone working on the repo gets the same skills, and changes go through pull requests that can be reviewed or reverted. Lander cites the dotnet/runtime repo's .github/skills folder, where he says Copilot picks up skills automatically depending on the prompt.
• Marketplace repos. These advertise skills through a marketplace.json file. Users install them with a command such as /plugin marketplace add dotnet/skills, which Lander describes as a wrapper around git clone. Skills installed this way live on your machine. They aren't in your repo unless you commit them, so a cloud agent such as the Copilot Web Agent won't see them.

NuGet adds a third option. Restore already fetches packages, so any SKILL.md files inside a package arrive on the machine too. Microsoft Learn explains the mechanism. Whenever you install, update or restore a package, NuGet manages packages in several folders outside your project structure. The default global-packages location on Windows is %userprofile%\.nuget\packages, and on Mac and Linux it is ~/.nuget/packages. Lander's demo uses a Mac. Learn also says that for PackageReference projects, packages are used directly from that folder rather than being copied into the project. That is the reason skills need extra tooling to reach your repository.

Restore also records the dependency graph in obj/project.assets.json. In Lander's example, grepping that file for SKILL.md lists five Markout skill paths. He then finds the same files under ~/.nuget/packages/markout/0.40.0/skills/. The practical gain is version co-location. Each package version can ship instructions that match its own APIs, much as a README does, but written for an agent rather than a human.

The two tools in the post​

Lander says the raw cache approach is workable but wants a better experience. He shows two tools.

dotnet-inspect​

Running dotnet-inspect package markout -S Skills lists the skills in the Markout package:

These sizes are as printed in the post. Adding --row 4 --print -12 prints the header of one skill. The tool can also read a project file. In the example, a console project with the Mockly package added reports Mockly 1.13.0 with a 7,409-byte skills/mockly/SKILL.md, covering HTTP mocking. The intent is that an agent can see which skills exist, then print them to its context or save them to a file.

Note the version detail in the post. The cache example uses Markout 0.40.0, while later output shows 0.40.1. Both appear in the post's different command outputs.

dotnet-package-skills​

This tool copies skills into the repo. In the demo, dotnet-package-skills install reads the solution and scans 23 direct packages. It copies five Markout skills to .agents/skills, ignores 22 packages with no valid bundled skills, and writes a .dotnet-package-skills.json file. The files show up as untracked in git, and git add . stages them.

The catch is that copies go stale. Lander says it's up to you to keep the skills in step as matching PackageReference versions change. He suggests a skill that does both jobs at once but doesn't present that as existing functionality. He also says NuGet MCP hasn't yet been updated for skills and that this is planned.

Cost and the "do no harm" rule​

The more interesting section is about evaluation. Lander says agents can already dig through the NuGet cache. They read READMEs and even write throwaway programs to reflect over assembly metadata. Frontier models do this creatively, but not cheaply. Skills aim to improve correctness and cost. They can also do the reverse if they are badly written or untested.

His reported findings, which are qualitative with no benchmark numbers in the post:

• Frontier models left little room to improve correctness.
• Weaker models showed significant underperformance and variability, which he attributes to poor compliance with skills.
• One skill set goes to every model. A 50% efficiency gain for a cheap model that costs a frontier model 10% more is a bad trade, because the frontier tokens cost more.
• He therefore uses a Pareto-style "do no harm" test and mainly tests with frontier models. Testing only with cheap models is called an anti-pattern.

That is one team's experience, not an industry standard. Even so, maintainers should take the core point seriously. A bundled skill spends your users' tokens, so it should earn them. Lander says maintainers should improve or remove skills that users report as ineffective or costly. Guidance for maintainers is still in progress.

The security question​

Markdown in packages has long been inert. Lander writes that agents change that. A skill is text an agent may read and follow. The post stops at the standard advice to use packages only from maintainers you trust. It doesn't give exploit details or a technical mitigation. It says safety guidance for consumers needs updating.

Independent commentary points the same way. One summary of research, from Atlan, claims over 99% of published SKILL.md files carry at least one "skill smell," and 36% of community skills carry a security flaw. That is a secondary source citing an academic study, and its figures concern community skills in general, not NuGet packages specifically. It still supports treating skill content as untrusted input.

What to do now​

Some practical steps, based on the post and general practice:

1. Check what you already have. Run a restore, then search obj/project.assets.json for SKILL.md to see whether any dependencies ship skills.
2. Review before use. Read bundled skills as you would a script from a third party, especially before committing them to the repo.
3. Decide where skills live. Leave them in the cache for convenience, or copy them into the repo (for example under .agents/skills) so every contributor and cloud agent sees them. If you copy, plan to re-sync on package updates.
4. If you maintain a package, ship a skill only if you can show it helps. Measure correctness and token cost across more than one model tier.
5. Don't assume your agent loads them. The Agent Skills spec defines what goes inside a skill folder but not where skills are stored or how an agent loads them. Whether a given agent finds package skills depends on that agent's own discovery rules.

Bottom line​

This is an experiment from the .NET team, not a NuGet platform feature. The package format, restore behavior and SKILL.md format are all existing pieces. What's new is the tooling that connects them and the case for versioned, self-documenting packages. The caveats are real: stale copies, token costs for users, uneven results on weaker models, and a trust problem that grows when agents act on package text. Used carefully, it could save agents from reverse-engineering your dependencies. Used carelessly, it could just be a new place to hide expensive or hostile instructions.