---

name: csharp-expert description: >- 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. license: MIT

C# Expert

Purpose

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.

Routing Contract

1. Classify the requested outcome from the prompt.
2. Inspect the smallest set of repository files needed to identify the solution type.
3. Compare both signals with the descriptions of the skills currently available to the runtime.
4. If the best skill is available and the user asked to perform the downstream work, invoke it with the 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.
5. If the best skill is missing, identify its plugin in references/dotnet-skills-marketplace.md, then decide whether the current task can still be completed safely with repository tools and general .NET knowledge.
6. Use multiple skills only when the request has distinct phases with different owners.
7. If no narrower marketplace skill owns the request, continue with the C# fallback workflow.

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:

• Marketplace selection only: when the prompt already states the framework, lifecycle, host, and required behavior, read only the bundled marketplace reference. Do not inspect the fixture, repository, GitHub, or plugin source. Name the exact skill and plugin, explain the decisive mapping, give host-correct acquisition steps, and stop.
• Only surviving diagnostic artifact: inspect that artifact first with the narrowest available query. For a supplied .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.

Step 1: Classify the Prompt

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.

Step 2: Detect the Solution Type

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.

Step 3: Match the Skill and Marketplace Plugin

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:

1. An exact transformation or lifecycle skill, such as a specific test migration, framework conversion, template operation, query optimization, or diagnostic collection workflow.
2. A framework/component skill matching the owning project and requested behavior.
3. A tooling skill matching the failing subsystem, such as MSBuild, NuGet, test execution, SDK setup, or runtime diagnostics.
4. A cross-cutting specialist matching the actual mechanism, such as interop, vectorization, serialization, AOT, or microbenchmarking.
5. csharp-refactoring for behavior-preserving structural change.
6. The C# language fallback below when no narrower available skill owns the work.

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:

1. If its skill appears in the runtime's available-skill catalog, invoke it immediately only when the operating mode requires downstream implementation. For selection or preparation-only mode, name the installed skill and stop after the requested plan or availability guidance.
2. If it does not appear, open references/dotnet-skills-marketplace.md and map the capability or skill name to the owning marketplace plugin.
3. Recommend the smallest plugin that contains the needed skill. Do not install every .NET plugin.
4. Follow the missing-skill workflow below. Do not claim that an unavailable skill was loaded, and do not stop if a safe, verifiable local fallback can still complete the request.

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