dotnet/skills: the .NET team's plugin marketplace for AI coding agents

The gap dotnet/skills fills: .NET work inside a coding agent

A general-purpose coding agent knows C# the way it knows any popular language: well enough to write a loop, poorly enough to miss the difference between MSTest and xUnit migration, or between a VSTest run and Microsoft.Testing.Platform. dotnet/skills is the .NET team's answer to that gap. It is a repository of skills and host-specific custom agents that a coding agent loads on demand, so the agent gets task-level instructions for builds, tests, data access, diagnostics, upgrades and MAUI instead of improvising.

The audience is narrow and identifiable. You are a .NET developer already using an agent host that supports plugins, and you want the agent to behave like someone who has read the MSBuild documentation. The repository ships fifteen plugins, from dotnet (high-level development plus C# language server integration) through dotnet-msbuild, dotnet-nuget, dotnet-upgrade, dotnet-test and dotnet-test-migration, to dotnet-ai, dotnet-blazor, dotnet-maui, dotnet-template-engine and dotnet11 for new .NET 11 APIs. That spread is the point: the unit of packaging is a task family, not a language.

How skills and agents actually load in each host

Two component types travel. Skills and MCP servers follow the Agent Plugins 1.0 specification, and skills themselves follow the agentskills.io open standard, which is why they can be installed into more than one host. The agents are not portable. Files under agents/*.agent.md use GitHub Copilot custom-agent conventions, and the README states plainly that they are not installed as native OpenAI Codex agents.

The reason is mechanical rather than political. Native Codex agents use .codex/agents/*.toml, and the README says this repository does not currently ship them because Codex plugin installation does not place agent files in those discovery locations. So a Codex user gets the skills and any Codex-compatible MCP servers the plugin declares, plus Codex's own dynamic subagent delegation, but not the Copilot static handoffs. The README also draws a line between Copilot's static UI handoff metadata, Codex plugin or custom-agent packaging, and OpenAI Agents SDK handoffs, which it describes as an application-level transfer between SDK-defined agents. If you were expecting one agent definition to work everywhere, this is where that expectation breaks.

Installing dotnet/skills in Copilot CLI or Claude Code

The primary path is the plugin marketplace. Launch Copilot CLI or Claude Code, register the repository as a marketplace, then install the plugin you want. The README gives this sequence:

/plugin marketplace add dotnet/skills
/plugin install <plugin>@dotnet-agent-skills

Restart the host to load the plugins. After the restart, the README says to run /skills to list available skills and /agents to list available agents. If the commands return nothing, the plugin did not load, and that is worth checking before you blame the skill. Updates are on demand rather than automatic:

/plugin update <plugin>@dotnet-agent-skills

For Codex CLI, the marketplace manifest ships at .agents/plugins/marketplace.json, and Codex CLI v0.121.0 and later supports the plugin marketplace. The commands differ from the Copilot form:

codex plugin marketplace add dotnet/skills
codex plugin marketplace upgrade dotnet-agent-skills

Between those two, launch Codex and open the plugin browser with /plugins, then browse the dotnet-agent-skills tab and install what you need. If you only want one skill, the README documents the skill-installer CLI with a GitHub URL of the form https://github.com/dotnet/skills/tree/main/plugins/<plugin>/skills/<skill-name>.

Cursor, VS Code and the preview caveat

Cursor consumes the repository as a Cursor plugin marketplace. You open the marketplace panel, search for .NET or browse cursor.com/marketplace, and install published plugins directly. For unpublished local changes, the README describes copying or symlinking a checkout to ~/.cursor/plugins/local/dotnet-agent-skills and then restarting Cursor or running Developer: Reload Window. That local path is the practical way to test a skill you are editing before it reaches the marketplace.

VS Code is explicitly a preview. The README marks plugin support as a preview feature subject to change and notes you may need to enable it first. The configuration is a settings.json entry:

// settings.json
{
  "chat.plugins.enabled": true,
  "chat.plugins.marketplaces": ["dotnet/skills"]
}

Once configured, the README says to type /plugins in Copilot Chat or use the @agentPlugins filter in Extensions to browse and install. Treat the VS Code route as the least settled of the four. "Subject to change" is not boilerplate here; it is the difference between a settings key that will still exist next quarter and one that will not.

Where dotnet/skills is the wrong tool

The clearest limitation is announced by the project itself. If you work primarily in Codex and your workflow depends on custom agents with defined handoffs, this repository does not deliver that today. You get skills, and you get Codex's built-in dynamic subagent delegation instead of a packaged agent graph. Anyone who installs the Codex plugin expecting parity with the Copilot experience will be disappointed, and the README says so before you install.

There is a second, quieter limitation. Nothing in the repository verifies that a skill fires when you expect it to. The README points to the Skill Value dashboard at dotnet.github.io/skills, which reports token use, elapsed time, activation, and not-passed rates by plugin, skill, executor model and judge model. That is a measurement surface, not a guarantee. Activation is model-dependent and host-dependent, so a skill that works in one combination may sit idle in another. If your task is a one-off refactor of a small project, installing a plugin marketplace to get there is more setup than the work itself. These skills pay off in repeated, specialized workflows: build failures, test migrations, package modernization, diagnostics.

Alternatives and the difference in approach

The obvious alternative is writing your own agent instructions: an AGENTS.md file in the repository, or host-specific prompt files, checked into your project. The difference is ownership and scope. Hand-written instructions live with your code and describe your conventions exactly, but they are yours to maintain and they do not travel between hosts. dotnet/skills is the inverse: maintained by the .NET team, packaged as a marketplace, installable into several hosts, and generic to .NET rather than specific to your codebase. The two are not exclusive. A team can install dotnet-msbuild for build diagnosis and still keep an AGENTS.md for internal conventions.

The second alternative is the individual skill-installer path the README documents. Instead of installing a plugin, you install one skill from a GitHub URL. That trades the plugin's bundled skills and MCP servers for a smaller footprint. It is the right choice when you want one capability and do not want the rest of a plugin's surface in your context. Note that the repository's own AGENTS.md and CONTRIBUTING.md are aimed at contributors, not consumers; if you plan to add a plugin, that is the documented route.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and its last push was on 2026-09-19. Releases split into two tracks. v1.0.0 was published on 2026-04-21, and skill-validator-nightly publishes on a nightly cadence, most recently on 2026-09-20. That combination tells you something about upgrade cost: the stable surface moves slowly, while validation tooling moves daily. If you pin to v1.0.0 you get a fixed point; if you install from the marketplace you are following main, and the README's update commands are the only upgrade mechanism it documents. There is no documented rollback procedure in the README, so pinning matters more than it would for a project that ships an undo path.

The licence is MIT, which is permissive and places few obligations on how you use the skills in your own work. That is a statement about the licence text, not legal advice; if you redistribute the skills inside a product, read LICENSE and your own counsel's guidance. One practical consequence of the marketplace model: plugin installs pull content the .NET team controls, so your agent's behaviour can change when they update a skill. If reproducibility matters to your team, record which plugin versions you installed and when.

Editorial conclusion

Adopt dotnet/skills if your team already drives a supported host (Copilot CLI, Claude Code, Codex CLI, Cursor, or VS Code with plugin support enabled) and wants .NET-specific behaviour without writing prompts from scratch. Do not adopt it expecting native Codex custom agents: the README states the repository does not ship .codex/agents/*.toml files today, and the agents/*.agent.md files are GitHub Copilot custom-agent conventions that Codex plugin installs do not expose. Before committing, add the marketplace, run /skills and /agents in your host, and check which of the fifteen plugins your workflow actually activates; the Skill Value dashboard at dotnet.github.io/skills reports activation and not-passed rates by plugin and model, which is the only evidence here about whether a skill fires.

Frequently asked questions

Official sources

1. dotnet/skills on GitHub
2. Issues
3. License: MIT
4. README
5. Releases