Konstantin Semenenko
July 23, 2026
5
minutes read
Four .NET skill catalogs matter in 2026, and they solve different problems. Microsoft's dotnet/skills is the official baseline: 15 domain plugins, marketplace install across Claude Code, Copilot, Cursor, and Codex, plus a public scoring dashboard and C# language-server integration. richlander/dotnet-skills is narrow and tool-focused, skills that teach agents to use specific .NET inspection tools. Aaronontheweb/dotnet-skills is a large, opinionated Claude Code-first catalog with its own evaluation harness. managedcode/dotnet-skills is the broadest, with dependency-driven install that reads your .csproj and picks matching skills. Start with Microsoft's, add the others where they cover what it doesn't.
Agent skills became a real part of .NET development in 2026, and there are now four catalogs worth knowing. The concept is simple: a skill is a lightweight package of specialized knowledge an agent can discover and load while solving a task, following the Agent Skills specification that Copilot CLI, Visual Studio, VS Code, Claude Code, Codex, and others support. What is less simple is choosing among the catalogs, because they are not competing implementations of the same thing, they make genuinely different bets about scope, distribution, and how skills get selected. Microsoft's official repository sets the baseline. Two individual .NET community catalogs take narrower or more opinionated positions. And our own catalog focuses on selecting skills from project dependencies. This is an honest map of all four and how to choose between them.
Full disclosure: we maintain one of the four catalogs discussed here (managedcode/dotnet-skills). We have tried to describe the others accurately, and every claim below is checkable in their public repositories.
The .NET team introduced dotnet/skills in March 2026 and shipped v1.0.0 the following month, and it has become the default starting point, currently sitting around 4,600 stars. It is organized as 15 domain plugins rather than one flat pile: dotnet (core), dotnet-data, dotnet-diag, dotnet-msbuild, dotnet-nuget, dotnet-upgrade, dotnet-maui, dotnet-ai, dotnet-test, dotnet-test-migration, dotnet-aspnetcore, dotnet-blazor, dotnet-template-engine, dotnet-advanced, and dotnet11 for new .NET 11 APIs.
Two things distinguish it beyond being official. First, install is marketplace-based across a wide surface, /plugin marketplace add dotnet/skills in Claude Code and Copilot CLI, a Cursor plugin marketplace, a Codex-native marketplace manifest, and preview support in VS Code. Second, it publishes a public dashboard tracking accuracy and efficiency scoring trends for its plugins, which is a genuinely unusual commitment to measuring whether skills actually help. It also includes C# language-server integration, giving agents real semantic code intelligence rather than only prose guidance, which no community catalog matches. If you install one thing, install this.
Rich Lander's catalog is small (around 34 stars) and deliberately narrow, and understanding its scope prevents a bad comparison. It is not a broad knowledge catalog; it is skills that describe how to use specific .NET tools that accelerate agent-driven development. It pairs with his related tools, dotnet-inspect for examining .NET assets, dotnet-find-type for locating types across a workspace using Roslyn, and dotnet-install-for-agents for analyzing a project's requirements and installing the right SDK.
That focus is the point. Instead of teaching an agent .NET patterns, it teaches an agent to use tools that give it precise, low-token answers about a codebase, find this type, inspect this package, determine this project's SDK requirement. It installs through the same plugin marketplace flow. Judge it as a complement to a knowledge catalog rather than an alternative to one: it makes an agent better at investigating a codebase, which is a different capability from knowing how EF Core should be used.
Aaron Stannard's catalog is large and opinionated, reported at roughly 167 skills and 16 sub-agents, covering C#, ASP.NET Core, Blazor, MAUI, EF Core, Akka.NET, Native AOT, testing, performance, and CI/CD, with patterns drawn from production systems. It targets Claude Code primarily, with documented paths for GitHub Copilot and OpenCode, and installs via plugin or a git clone plus copy.
What makes it notable is the engineering discipline around it. There is a separate evaluation repository that uses DSPy to test whether models correctly activate and benefit from the skills, measuring skill activation accuracy rather than assuming it. And the design follows progressive disclosure deliberately: keep core patterns in a SKILL.md under about 500 lines and move detailed reference material into sibling files loaded on demand, so the agent gets focused guidance by default. That is a token-efficiency argument, and it is the same problem our own catalog attacks from a different angle. If you work primarily in Claude Code and want deep opinionated coverage including Akka.NET, this is a strong choice.
Our catalog is the broadest of the four: 185 skills, 26 orchestration agents, 23 collections, and 13 bundles, spanning Claude Code, GitHub Copilot, Gemini, Codex, and Junie. It is distributed as a .NET global tool (dotnet tool install --global dotnet-skills) rather than registered as a per-agent marketplace, which is a deliberate difference: the CLI is the install surface, and it writes into whichever agent directories exist.
The bet we made is on selection rather than browsing. Every skill declares the NuGet package prefixes it applies to (Microsoft.EntityFrameworkCore.* for the EF Core skill, Microsoft.AspNetCore.Components.* for Blazor, Aspire.* for .NET Aspire), so dotnet skills install --auto reads your .csproj and installs the skills matching your actual dependencies. That matters because the full catalog is 387,424 tokens, and each skill page exposes its own token count (dotnet skills catalog tokens) precisely so the cost is visible. Bundles cover the cases where dependencies do not tell the whole story, dotnet skills install bundle quality lays down the formatter, analyzers, complexity checks, and CRAP analysis as one command. The orchestration agents sit above the skills and route work to the right guidance rather than expecting the model to pick from 185 options.
They overlap less than the shared name suggests, so the practical answer is usually a combination:
The honest summary: Microsoft owns the baseline and the platform integration, the community catalogs each solve a specific problem better than a general catalog would, and no one has solved skill selection at scale yet. That last problem is the one worth watching, because as catalogs grow past a hundred skills, deciding what to install stops being a browsing task and becomes an engineering one.
The 2026 .NET skills ecosystem has four catalogs making different bets. Microsoft's dotnet/skills is the official baseline: 15 domain plugins, broad marketplace distribution, public accuracy scoring, and C# language-server integration. richlander/dotnet-skills is narrow and tool-focused, teaching agents to use .NET inspection tooling. Aaronontheweb/dotnet-skills is a large Claude Code-first catalog with a DSPy evaluation harness and progressive-disclosure design. managedcode/dotnet-skills is the broadest, with dependency-driven install that reads your .csproj, per-skill token accounting, bundles, and five platform targets. Start with Microsoft's, layer the others where they cover what it does not, and watch whether the SDK absorbs skill distribution.
If you want a .NET AI setup where the agent actually knows your stack, from skill selection to the verification around it, that is where our AI Dev Team work starts.
What are .NET agent skills? Lightweight packages of specialized knowledge that an AI coding agent can discover and load while working on a task, following the Agent Skills specification. They give the agent current, specific .NET guidance instead of relying on whatever patterns it absorbed during training.
Which .NET skills catalog should I use? Start with Microsoft's official dotnet/skills, since it is maintained by the .NET team, publicly measured, and includes C# language-server integration. Then add community catalogs for what they cover better: richlander's for tool-use and codebase inspection, Aaronontheweb's for deep Claude Code-focused coverage, ours for dependency-driven install and broader platform support.
What is the difference between Microsoft's dotnet/skills and community catalogs? Microsoft's is the official baseline with 15 domain plugins, marketplace distribution across Claude Code, Copilot, Cursor, and Codex, a public scoring dashboard, and language-server integration. Community catalogs are typically broader or more opinionated in specific areas and experiment with distribution and selection mechanisms the official repository has not adopted.
How do I install .NET skills? It depends on the catalog. Microsoft's, richlander's, and Aaronontheweb's install through plugin marketplaces (for example /plugin marketplace add dotnet/skills in Claude Code or Copilot CLI). Ours installs as a .NET global tool with dotnet tool install --global dotnet-skills, then dotnet skills install --auto or a bundle command.
Can I use more than one .NET skills catalog? Yes, and it is often the right approach, since they cover different ground. The practical constraint is context budget rather than compatibility: every installed skill consumes tokens, so installing several full catalogs at once is usually worse than selecting deliberately from each.
[Image: a comparison table of four .NET skill catalogs across rows for scope, distribution method, platform support, and distinguishing feature, with Microsoft's marked as the official baseline, richlander's as tool-focused, Aaronontheweb's as Claude Code-first with evals, and managedcode's as dependency-driven with token accounting]
