Route C# and .NET requests to the exact installed specialist or smallest dotnet/skills marketplace plugin. USE FOR: "which specialist should own this" or "how do I add the skill" requests involving ASP.NET Core endpoints, Blazor, MAUI binding, Windows Forms specialist selection or installation, EF Core queries, test or framework migration, runtime CPU/allocation evidence, file-based C#, editor/compiler defects, a surviving MSBuild `.binlog`, or a plugin missing from `/skills`; also use for C# semantics when no narrower specialist exists. DO NOT USE FOR: requests that already name the exact installed specialist to invoke, or work unrelated to C# or .NET.
Permissions
Files
Route C# and .NET requests to the exact installed specialist or smallest dotnet/skills marketplace plugin. USE FOR: "which specialist should own this" or "how do I add the skill" requests involving ASP.NET Core endpoints, Blazor, MAUI binding, Windows Forms specialist selection or installation, EF Core queries, test or framework migration, runtime CPU/allocation evidence, file-based C#, editor/compiler defects, a surviving MSBuild `.binlog`, or a plugin missing from `/skills`; also use for C# semantics when no narrower specialist exists. DO NOT USE FOR: requests that already name the exact installed specialist to invoke, or work unrelated to C# or .NET.
Act as the front door for C# and .NET work. Determine what the user wants, identify the kind of
solution that owns the work, invoke the narrowest installed specialist, and give exact
dotnet/skills marketplace installation steps when that specialist is missing. Keep direct C#
language guidance as the fallback, not the default.
Version history
skill tool as the first external action; do not emit a routing explanation before the
invocation and do not merely recommend the skill. For selection or preparation-only requests,
name the installed specialist and stop without invoking it.references/dotnet-skills-marketplace.md, then decide whether the current task can still be
completed safely with repository tools and general .NET knowledge.Routing is not task completion. A missing specialist changes the confidence and preferred workflow; it does not automatically justify stopping. Continue in the same turn when the task can be completed and validated without the specialist. Stop for installation only when the missing capability is actually required to proceed safely or the user asked specifically to install or load it.
Use these fast paths before general repository exploration:
.binlog, do not glob, list, or search unrelated workspace files before
extracting its recorded error, property, target, and path evidence.Choose the operating mode from the user's requested outcome:
| User asks for | Required behavior |
|---|---|
| Implement, fix, diagnose, migrate, or create | Invoke the installed specialist, or complete a safe local fallback. If a narrower specialist exists but is unavailable, report its optional plugin afterward unless the user prohibited installation advice. |
| Identify, choose, install, prepare, or load the right marketplace capability | Inspect enough solution evidence to choose the owner, name it whether installed or missing, give acquisition steps only when needed, and stop without invoking the specialist, editing files, or generating the requested application artifact. |
Recover a plugin already installed but absent from /skills | Refresh discovery first; do not reinstall or update on the first response. |
Choose one owner per phase. Do not expose internal routing ceremony or turn the answer into a menu.
Identify the primary action before inspecting implementation details.
| Prompt intent | Prefer skills whose description owns |
|---|---|
| Create or scaffold | Project/template creation for the detected solution type |
| Add application behavior | The framework or component where the behavior lives |
| Fix a compiler/runtime defect | The narrow language, framework, data, or interop owner |
| Build or restore failure | MSBuild, SDK, workload, project-reference, or NuGet diagnosis |
| Write, run, review, or migrate tests | The exact testing lifecycle or migration requested |
| Upgrade or migrate | The source version, target version, and artifact being migrated |
| Diagnose slowness, crash, hang, or memory growth | Runtime diagnostics unless evidence points to build performance or a local code hot path |
| Refactor without changing behavior | Refactoring rather than feature or bug-fix guidance |
| Package, publish, or trust a feed | NuGet/package-publishing workflow |
| Ask about C# syntax, types, nullability, async, or APIs | A language specialist unless solution-specific behavior is load-bearing |
Treat user nouns as clues, not proof. "Performance" may mean runtime tracing, a microbenchmark, EF query shape, SIMD, allocation-heavy C#, or MSBuild evaluation. "API" may mean ASP.NET Core, a public library contract, or an external service client.
When a deployed .NET process needs CPU and allocation evidence and no observability vendor is named, prefer the vendor-neutral .NET runtime diagnostics route. Do not substitute an APM-vendor agent for raw process evidence merely because it can also report performance data. In a selection answer, state that runtime trace collection gathers deployed-process evidence before a hot method is known, whereas source optimization starts from code or an already identified hot path.
Inspect only likely manifests and nearby owning files. Prefer a solution/project file and the file named by the prompt over broad repository searches.
Use LSP navigation when available to trace a prompt-named symbol or file to its owning project and nearby callers. Use LSP diagnostics as early evidence, but do not treat them as a substitute for the specialist's required build or runtime validation.
When the prompt names a C# source file with an editor/compiler defect and LSP is available, request diagnostics before running a build or broad search. Use the diagnostic location and code to scope the edit, request diagnostics again after the edit, then run the narrowest build or test that proves the fix.
| Evidence | Solution or concern |
|---|---|
Microsoft.NET.Sdk.Web, controllers, endpoints, middleware, OpenAPI | ASP.NET Core |
.razor, AddRazorComponents, Blazor bootstrapping | Blazor |
<UseMaui>true</UseMaui>, MauiProgram, XAML pages | .NET MAUI |
<UseWindowsForms>true</UseWindowsForms>, Form, designer files | Windows Forms |
EF Core package references, DbContext, migrations | .NET data / EF Core |
<IsTestProject>true</IsTestProject>, test SDK/framework packages | .NET testing |
Directory.Build.*, custom targets/tasks, .binlog, evaluation errors | MSBuild |
Directory.Packages.props, package restore/version conflicts, feeds | NuGet |
| Old and new TFMs, framework-version migration request, compatibility warnings | .NET upgrade |
PublishAot, trimming warnings, native library calls | AOT, interop, or deployment compatibility |
| Aspire AppHost or distributed-application model | Aspire |
| AI/ML/LLM packages or agent/RAG/MCP application code | .NET AI |
| No project plus an explicit request for a one-file C# program | File-based C# |
| None of the above; correctness depends on C# semantics | C# language fallback |
When several project types exist, trace from the file or behavior named in the prompt to its owning
project. Do not route the whole solution from the first .csproj found.
Use the runtime-provided available-skill names and descriptions as the source of truth. Do not search for a skill installation directory or invoke a remembered skill that is not currently available.
Rank candidates in this order:
csharp-refactoring for behavior-preserving structural change.Because csharp-expert ships in the core dotnet plugin, prefer its installed sibling skills
csharp-refactoring, msbuild, and setup-local-sdk when they own the request. Do not require the
user to install dotnet-msbuild merely to analyze an ordinary build failure or binlog that the
core msbuild entry already covers.
The most specific noun is not always the owner. Route by the decision that determines success:
| Ambiguous request | Distinguishing evidence |
|---|---|
| "Make this faster" | Build duration -> build-performance skill; SQL/query shape -> data skill; process CPU/memory -> diagnostics; isolated code comparison -> microbenchmarking/vectorization |
| "Fix the API" | HTTP pipeline/endpoint -> ASP.NET Core; public type contract -> C# fallback; JSON version behavior -> serialization specialist |
| "Upgrade the tests" | Framework version change -> exact migration skill; failing execution -> run-tests/platform skill; quality review -> analysis skill |
| "Fix nullability" | Project-wide nullable adoption -> migration skill; one incorrect flow/contract -> C# fallback; generated framework binding -> owning framework skill |
| "Add authentication" | Framework-specific application auth -> owning framework skill; token parsing primitive -> C# fallback |
If two candidates remain plausible, gather one more decisive artifact rather than loading both.
After selecting the capability:
references/dotnet-skills-marketplace.md and map the capability or
skill name to the owning marketplace plugin.When the bundled reference contains a maintained marketplace capability, recommend that capability. Do not ask the user to author a repository-local agent or skill as a substitute. For migrations, state the source-to-target lifecycle and parameterization mappings that make the chosen capability fit, not only its name.
For marketplace-planning requests, name both the narrow skill and its plugin. Use project evidence to disambiguate framework nouns, but do not perform the downstream implementation the user asked to prepare for.
For migration selection, quote concrete source-to-target syntax from the bundled reference: include at least one lifecycle mapping and one parameterization mapping instead of saying only that those behaviors are supported.
Use the bundled marketplace reference as the authoritative lookup. Do not search GitHub, inspect unrelated plugin source, or enumerate alternatives after the prompt and one nearby manifest already identify the owner. If the prompt already names the source and target lifecycle or an unambiguous artifact constraint, do not inspect files merely to reconfirm it. A selection request that states the framework, lifecycle, and required behavior needs no repository search: read only the bundled reference, choose the owner, and answer. Do not inspect the local skill source, marketplace checkout, or fixture merely to prove that a named capability exists.
Answer in four compact parts:
For a selection answer, completeness beats extra exploration. Read the bundled reference once, then answer. Do not call host help, search the web, or inspect plugin source to reconfirm commands already present in the reference.
Do not add a Route: header in marketplace-planning mode; lead with the capability and plugin.
Do not mention this skill's step numbers, fallback labels, routing contract, or internal selection
process in the user-facing answer.
For GitHub Copilot CLI or Claude Code, give these exact commands with the selected plugin substituted:
/plugin marketplace add dotnet/skills
/plugin install <plugin>@dotnet-agent-skills
When installation is the next step, require:
Restart the host, run `/skills` to confirm the specialist is available, and rerun the request.
When the task can proceed without the specialist:
If the user explicitly says not to recommend or discuss installation, omit the missing-plugin sentence and all acquisition guidance. Complete and validate the safe fallback with the capabilities available in the current run.
This reduced-coverage path may still perform framework, migration, diagnostics, or tooling work. Preserve the selected domain's invariants and report specialist-specific checks that were unavailable.
Rules:
dotnet-agent-skills; the source repository is dotnet/skills./skills
before recommending a reinstall.references/dotnet-skills-marketplace.md.When the user says the plugin is already installed but its skills are absent:
/skills./skills reload, or invented explicit-invocation commands.Only after the user reports that restart plus /skills still fails should the next response move to
host-specific update or reinstall diagnostics.
Use a sequence only when phases are independently owned. Examples:
Do not chain skills that duplicate each other, load an entire plugin "just in case", or use a generic skill before a specialist that already owns the request. After a specialist is loaded, follow its workflow and boundaries.
If one or more phase specialists are missing but ordinary dotnet commands and repository edits
can complete the phases, execute the phases in order and report the optional plugins afterward.
Do not defer an entire multi-phase request solely because the ideal plugin set is unavailable.
Use this only when no narrower available skill matches and the load-bearing problem is C# language or runtime semantics.
For a marketplace-planning request whose correct route is this fallback, say: No additional marketplace plugin is required; the loaded csharp-expert skill owns this C# semantic fix. Do not
claim that no skill or specialist is involved.
Do not raise the SDK, TFM, language version, package versions, or analyzer settings merely to make a local C# edit compile. Do not edit generated files. Do not use broad casts, null-forgiving operators, catch-all handlers, or fire-and-forget work to hide evidence.
When a framework type provides an ownership-preserving overload such as leaveOpen: true, give that
canonical fix only. Never suggest intentionally leaking or skipping disposal of a disposable
wrapper as an alternative. Preserve the example's observable behavior: do not add null coalescing,
change a nullable return to a non-null value, alter access modifiers, or invent unrelated error
handling merely to make a conceptual snippet look more complete. If an example directly returns
StreamReader.ReadLine(), use a nullable string? return in nullable-aware C#; do not show
string while claiming that the existing null-on-end-of-stream behavior is preserved.
dotnet/skills plugin installation
command. Continue immediately with an explicit reduced-coverage fallback whenever standard tools
can still complete and validate the task.schemas/prod.json the repository root, and explicitly rule out build or CI configuration
changes when the recorded command already proves the configured path.In these kits
More from @dotnet
Works with
Claude, Codex, Cursor & more