Konstantin Semenenko
July 23, 2026
4
minutes read
Agent skills solve a real problem (models default to outdated .NET patterns) and create a new one: every installed skill sits in the context budget. Our full catalog is 185 skills and 387,424 tokens. A typical ASP.NET Core plus EF Core service needs a handful, and loading the rest costs money and degrades the model's attention. The fix is selecting by dependency: skills declare the NuGet package prefixes they apply to, and dotnet skills install --auto reads your .csproj and installs only what matches.
Installing agent skills has an obvious upside and a less obvious cost. The upside is that a coding agent stops writing .NET the way it learned to during training and starts following current guidance for the libraries you actually use. The cost is that every skill you install occupies part of the context budget, and context is not free: it is billed on every call and it degrades model performance as it fills. Our dotnet-skills catalog is currently 185 skills totalling 387,424 tokens. No project needs all of it. A typical ASP.NET Core service with EF Core needs a handful, and the other 179 skills are pure overhead, tokens you pay for and attention the model spends on guidance irrelevant to your codebase. This is why we built skill selection around project dependencies rather than browsing, and this explains the reasoning and the mechanism.
The intuition that a bigger catalog installed means a smarter agent is wrong for the same reason that a bigger context window does not make a better agent. Loading everything degrades output. Once a context window fills past a certain fraction, accuracy drops measurably, a phenomenon widely called context rot, and it inflates both cost and latency at the same time, since every token in the window is re-read and re-billed on each model call. We covered the mechanism in context engineering; skills are a concrete instance of it.
Do the arithmetic on a real case. A service using ASP.NET Core and EF Core needs, roughly, the ASP.NET Core skill (1,795 tokens), the EF Core skill (2,104), and a few foundation and quality skills. Call it under 10,000 tokens of genuinely relevant guidance. Installing the full catalog instead puts 387,424 tokens of material in play, of which the overwhelming majority concerns MAUI, Blazor, Orleans, Azure Functions, XR, legacy Entity Framework 6, and a dozen other areas your project does not touch. That is not a smarter agent, it is a more expensive and more distracted one, being asked to route around guidance that does not apply. Skill count is a vanity metric; skill relevance is the useful one.
The mechanism that makes selection automatic is simple and sits in the catalog metadata rather than in a heuristic. Every skill declares the NuGet package prefixes it covers. The EF Core skill declares Microsoft.EntityFrameworkCore.*. The Blazor skill declares Microsoft.AspNetCore.Components.*. The Aspire skill declares Aspire.*. Azure Functions declares Microsoft.Azure.Functions.*. Those declarations turn "which skills does this project need" from a judgment call into a lookup, and every entry in the skill directory shows the prefixes it matches.
Given that, dotnet skills install --auto reads the .csproj files in your project, extracts the package references, matches them against the declared prefixes, and installs the skills that match. A project referencing Microsoft.EntityFrameworkCore.SqlServer and Microsoft.AspNetCore.OpenApi gets the EF Core and ASP.NET Core skills and does not get MAUI or Orleans. If you later add Aspire, running it again picks up the Aspire skill. The selection follows the dependencies because the dependencies are the honest signal of what the project actually is, and unlike a curated starter list, it stays correct as the project changes.
Dependency detection has a real limit worth naming: some skills apply to how you work rather than to what you reference. Code quality is the clearest example. There is no NuGet package that means "this team cares about analyzer configuration and complexity thresholds," so no amount of .csproj scanning will infer it. The same is true for architecture guidance, testing approach, and delivery process, these are choices, not dependencies.
Bundles cover that half. A bundle is a curated multi-skill install for an intent rather than a dependency, and it runs as one command. dotnet skills install bundle quality installs the .NET quality toolchain, formatter, analyzers, complexity checks, CRAP analysis, editorconfig guidance, and CI quality checks, ten skills and 13,007 tokens as a deliberate choice. dotnet skills install bundle testing-xunit lays down the testing baseline plus xUnit guidance. dotnet skills install bundle foundations gives the core .NET baseline in 3,705 tokens. So the model is: --auto handles what your dependencies imply, bundles handle what your intentions imply, and between them you get a focused install rather than a full catalog dump.
The reason we expose token counts at all is that an invisible cost is a cost nobody manages. Every skill page in the catalog shows its token count, every collection shows what falls under it, and dotnet skills catalog tokens --catalog-root . exports per-skill counts so you can see exactly what an install adds to the context budget. That turns a vague worry ("are we loading too much?") into a number you can decide against.
This matters more as catalogs grow. The .NET skills ecosystem has expanded fast in 2026, with Microsoft's official repository, several substantial community catalogs, and our own, and the natural trajectory is more skills, not fewer. At that scale, the question stops being "which catalog has the most skills" and becomes "how do I install only what this project needs." Aaron Stannard's catalog attacks the same problem from a different angle with progressive disclosure, keeping SKILL.md files small and loading detail on demand, which is a good complementary answer. Both approaches accept the same premise: context budget is the binding constraint, and the design job is spending it well.
Practical guidance:
The general rule: install for the project in front of you, not for the .NET ecosystem in general.
An AI agent does not benefit from having every skill installed, it benefits from having the right ones, because every skill occupies a context budget that is billed on each call and degrades model attention as it fills. Our catalog is 185 skills and 387,424 tokens, and a typical ASP.NET Core plus EF Core service needs well under 10,000 of them. Because skills declare the NuGet package prefixes they apply to, dotnet skills install --auto can read your .csproj and install exactly the matching set, while bundles cover the intent-driven skills that dependencies cannot infer, like quality and testing. Make the token cost visible, install for your project rather than the ecosystem, and re-run detection as dependencies change. Skill selection is a context-budget problem.
If you want .NET AI tooling set up so the agent knows your stack without drowning in irrelevant context, that is where our AI Dev Team work starts.
Why shouldn't I install every available agent skill? Because every installed skill consumes context budget, which is billed on each model call and degrades accuracy as the window fills (context rot). A full 387,424-token catalog for a project that needs under 10,000 tokens of relevant guidance is more expensive and more distracted, not smarter.
How does automatic skill detection work? Each skill declares the NuGet package prefixes it applies to (for example Microsoft.EntityFrameworkCore.* for the EF Core skill). The command dotnet skills install --auto reads your .csproj files, extracts package references, matches them against those declarations, and installs only the skills that match your actual dependencies.
How many skills does a typical .NET project need? Usually a handful. An ASP.NET Core service with EF Core needs those two framework skills (about 3,900 tokens combined) plus a few foundation and quality skills, well under 10,000 tokens, rather than the full catalog.
What if a skill I need isn't tied to a NuGet package? That is what bundles are for. Code quality, testing approach, and architecture guidance reflect how a team works rather than what it references, so no .csproj scan can infer them. Bundles install those as one command, for example dotnet skills install bundle quality.
How do I know how many tokens my skills are using? Each skill page shows its token count, and dotnet skills catalog tokens --catalog-root . exports per-skill counts for the whole catalog. Making the cost visible is what lets you decide whether a marginal skill is worth its share of the context budget.
