/csharp-expert

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