Csharp Expert

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:

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.

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.

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:

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 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:

1. Exact skill name and plugin; never substitute a generic capability label when the bundled reference contains an exact route.
2. One sentence matching the decisive behavior or artifact evidence. Use the user's concrete mechanism: N+1/database round trips for repeated EF related-data queries; deployed-process CPU/allocation collection before a known hot path for runtime tracing; source and target TFM plus compatibility work for upgrades.
3. Host-correct install steps.
4. Restart/discovery verification, when the host requires it.

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.