Dotnet

.NET Router Skill

Trigger On

• the user asks for general .NET help without naming a narrower framework or tool
• implementing, debugging, reviewing, or refactoring C# or .NET code in a repo with multiple app models or frameworks
• deciding which .NET skill should own a task before editing code
• tasks that combine platform work with testing, quality, architecture, setup, or migration decisions

Workflow

1. Detect the real stack first:

• target frameworks and SDK version
• LangVersion
• project SDKs and workload hints
• hosting model and app entry points
• test framework and runner
• analyzers, formatters, coverage, and CI quality gates

2. Route to the narrowest platform skill as soon as the stack is known:

• Web: aspnet-core, minimal-apis, web-api, blazor, signalr, grpc
• Cloud and hosting: aspire, azure-functions, worker-services
• Desktop and client: maui, wpf, winforms, winui
• Data and distributed: entity-framework-core, entity-framework6, orleans
• AI and agentic: semantic-kernel, microsoft-extensions-ai, microsoft-agent-framework, mlnet, mixed-reality
• Legacy: legacy-aspnet, wcf, workflow-foundation

3. Route cross-cutting work to the companion skill instead of keeping it inside generic .NET advice:

• project bootstrap or repo shape: project-setup, architecture
• frontend asset analysis in mixed .NET plus Node repos: eslint, stylelint, htmlhint, webhint, biome, sonarjs, metalint, chous
• code review: code-review
• language features: modern-csharp
• testing: tunit, xunit, mstest
• format, analyzers, coverage, and CI: format, code-analysis, quality-ci, coverlet, reportgenerator
• maintainability and architecture rules: complexity, netarchtest, archunitnet

4. If more than one specialized skill applies, prefer the one closest to the user-visible behavior first, then pull in the quality or tooling skill second. 5. Do not stop at this skill once a narrower match exists. This skill should classify and hand off, not become a generic dumping ground. 6. After code changes, validate with the repository's actual build, test, and quality workflow instead of generic .NET commands.

Current Upstream Notes

• .NET 9.0.17 runtime and ASP.NET Core releases are servicing updates. Treat them as patch validation work unless the repo shows a concrete affected area such as WebSocket frame handling, JIT loop cloning, QUIC/MsQuic, or Linux CRL caching.
• .NET SDK 8.0.422 belongs to the 8.0.28 servicing train. Use it for repos pinned to .NET 8, but do not infer modern C# or .NET 10 language availability from that SDK line.
• The refreshed "Build apps with .NET" Learn page remains broad routing context; still hand off to project-setup, worker-services, aspnet-core, modern-csharp, or another narrow skill as soon as the app model is known.

Routing Heuristics

• If the repo contains Microsoft.NET.Sdk.Web, start from a web skill, not generic .NET.
• If the repo contains Blazor, Razor Components, or .razor pages, prefer blazor.
• If the repo contains package.json, frontend lint configs, or browser-facing asset pipelines inside the .NET solution, prefer the dedicated frontend analysis skills instead of generic .NET.
• If the repo contains Orleans grains or silo hosting, prefer orleans.
• If the repo is mostly analyzers, CI, or coverage work, prefer the quality skill directly.
• If the user asks about “which skill should I use?”, answer with the narrowest matching skill and explain why in one short sentence.
• If no narrower skill matches, keep the work here and stay explicit about the missing specialization.

Deliver

• the correct specialized skill choice for the task
• repo-compatible code or documentation changes that stay aligned with the detected stack
• validation evidence that matches the real project runner and quality toolchain

Validate

• the chosen downstream skill actually exists in the catalog
• platform assumptions match project SDKs, packages, and workloads
• generic guidance has been replaced by framework-specific guidance whenever possible
• runner-specific commands are not mixed incorrectly
• language or runtime features are only used when the repo supports them

Documentation

References

• references/routing.md - Decision tree for routing tasks to specialized .NET skills, including app model classification and cross-cutting concern handling.
• references/detection.md - Project detection patterns for identifying SDK types, target frameworks, workloads, language versions, and app models.

Project Detection Patterns

This reference defines detection patterns for identifying .NET project characteristics including SDK types, target frameworks, workloads, and app models.

SDK Detection

Project SDK Types

Detect the SDK from the <Project Sdk="..."> attribute in .csproj/.fsproj/.vbproj files:

SDK Version Detection

Check global.json for SDK version constraints:

{
  "sdk": {
    "version": "10.0.100",
    "rollForward": "latestMinor"
  }
}

Key SDK version ranges:

• 10.0.x - .NET 10 (LTS, supported until November 2028)
• 9.0.x - .NET 9 (STS, supported until November 2026)
• 8.0.x - .NET 8 (LTS, supported until November 2026)
• 7.0.x - .NET 7 (end of support)
• 6.0.x - .NET 6 (end of support)
• 5.0.x - .NET 5 (end of support)
• 3.1.x - .NET Core 3.1 (end of support)

Target Framework Detection

Target Framework Monikers (TFM)

Detect from <TargetFramework> or <TargetFrameworks> in project files:

Multi-Targeting

Projects with <TargetFrameworks> (plural) target multiple platforms:

<TargetFrameworks>net10.0;net10.0-windows;net10.0-ios;net10.0-android</TargetFrameworks>

Workload Detection

Installed Workloads

Check installed workloads via:

dotnet workload list

Project-Implied Workloads

Workload Manifest Files

Check for workload requirements in:

• .config/dotnet-tools.json - local tools
• Directory.Build.props - workload version pins
• NuGet.config - custom feeds for preview workloads

Language Version Detection

LangVersion Property

Detect from <LangVersion> in project files or Directory.Build.props:

Implicit Language Version

When <LangVersion> is not specified, the SDK sets it based on TFM:

• net10.0 implies C# 14
• net9.0 implies C# 13
• net8.0 implies C# 12
• net7.0 implies C# 11
• net6.0 implies C# 10

App Model Detection

Web Apps

Look for these indicators:

ASP.NET Core general:

• Program.cs with WebApplication.CreateBuilder
• Startup.cs with ConfigureServices/Configure
• appsettings.json, appsettings.Development.json
• wwwroot/ folder

Blazor:

• .razor files
• @page directive
• RenderModeInteractiveServer, RenderModeInteractiveWebAssembly
• AddInteractiveServerComponents(), AddInteractiveWebAssemblyComponents()
• _Imports.razor

Minimal APIs:

• app.MapGet(), app.MapPost(), etc.
• No [ApiController] classes
• Route handlers as lambdas or delegates

MVC/Web API:

• Controllers/ folder
• Classes inheriting Controller or ControllerBase
• [ApiController], [Route], [HttpGet] attributes

SignalR:

• Classes inheriting Hub or Hub<T>
• IHubContext<T> injection
• MapHub<T>() calls

gRPC:

• .proto files
• Grpc.AspNetCore package
• MapGrpcService<T>() calls

Desktop Apps

MAUI:

• MauiProgram.cs
• MauiApp.CreateBuilder()
• .maui file extensions
• Microsoft.Maui.* namespaces

WPF:

• <UseWPF>true</UseWPF> in project
• .xaml files with WPF namespaces
• PresentationFramework reference
• App.xaml, MainWindow.xaml

WinForms:

• <UseWindowsForms>true</UseWindowsForms> in project
• System.Windows.Forms namespace
• Form class inheritance
• .Designer.cs files

WinUI 3:

• Microsoft.WindowsAppSDK package
• Microsoft.WinUI namespace
• WinUIEx patterns

Uno Platform:

• Uno.WinUI or Uno.UI packages
• Cross-platform XAML with Uno namespaces
• Platform head projects

Worker and Background Services

• <OutputType>Exe</OutputType> with no web SDK
• BackgroundService inheritance
• IHostedService implementation
• Host.CreateDefaultBuilder() without web

Azure Functions

• [Function] attribute
• Microsoft.Azure.Functions.Worker namespace
• host.json file
• local.settings.json file

Aspire

App Host:

• Aspire.AppHost.Sdk
• DistributedApplicationBuilder
• builder.AddProject<T>()

Service Defaults:

• Aspire.ServiceDefaults.Sdk
• AddServiceDefaults() extension

Component Usage:

• Aspire.* packages
• AddRedis(), AddPostgres(), etc.

Test Framework Detection

Build and Quality Tooling Detection

Analyzers

Formatters

Coverage

Architecture Testing

Common File Locations

Routing Decision Tree

This reference defines the decision tree for routing tasks from the generic dotnet skill to the narrowest matching specialized skill.

Primary Classification

Start by classifying the repository or task by its primary app model, then refine by cross-cutting concerns.

Is the task about a specific framework or platform?
|
+-- YES --> Route to the platform skill immediately
|
+-- NO --> Continue to app model detection

App Model Detection Order

Evaluate project indicators in this order and route to the first matching skill:

1. Web and API

2. Cloud and Hosting

3. Desktop and Client

4. Data and Distributed

5. AI and Agentic

6. Legacy

Cross-Cutting Concerns

After platform routing, check if the task is primarily about a cross-cutting concern:

Project and Architecture

Code Quality and Review

Testing

Formatting and Analysis

Quality and CI

Architecture Enforcement

Multi-Skill Tasks

When a task spans multiple skills:

1. Prefer the user-visible behavior skill first - if the task is about adding a Blazor feature with tests, start with blazor 2. Pull in quality/tooling skills second - after the feature is implemented, route testing to xunit or tunit 3. Do not combine incompatible guidance - runner-specific commands and patterns should come from one skill at a time

Fallback Behavior

If no narrower skill matches:

1. Stay at dotnet skill 2. Be explicit about missing specialization 3. Provide generic .NET guidance only when necessary 4. Suggest which skill should be created if the gap is recurring