$npx -y skills add managedcode/dotnet-skills --skill dotnetPrimary router skill for broad .NET work. Classify the repo by app model and cross-cutting concern first, then switch to the narrowest matching .NET skill instead of staying at a generic layer. USE FOR: general .NET requests without a narrower framework; C# implementation, debugg
| 1 | # .NET Router Skill |
| 2 | |
| 3 | ## Trigger On |
| 4 | |
| 5 | - the user asks for general `.NET` help without naming a narrower framework or tool |
| 6 | - implementing, debugging, reviewing, or refactoring C# or `.NET` code in a repo with multiple app models or frameworks |
| 7 | - deciding which `.NET` skill should own a task before editing code |
| 8 | - tasks that combine platform work with testing, quality, architecture, setup, or migration decisions |
| 9 | |
| 10 | ## Workflow |
| 11 | |
| 12 | 1. Detect the real stack first: |
| 13 | - target frameworks and SDK version |
| 14 | - `LangVersion` |
| 15 | - project SDKs and workload hints |
| 16 | - hosting model and app entry points |
| 17 | - test framework and runner |
| 18 | - analyzers, formatters, coverage, and CI quality gates |
| 19 | 2. Route to the narrowest platform skill as soon as the stack is known: |
| 20 | - Web: `aspnet-core`, `minimal-apis`, `web-api`, `blazor`, `signalr`, `grpc` |
| 21 | - Cloud and hosting: `aspire`, `azure-functions`, `worker-services` |
| 22 | - Desktop and client: `maui`, `wpf`, `winforms`, `winui` |
| 23 | - Data and distributed: `entity-framework-core`, `entity-framework6`, `orleans` |
| 24 | - AI and agentic: `semantic-kernel`, `microsoft-extensions-ai`, `microsoft-agent-framework`, `mlnet`, `mixed-reality` |
| 25 | - Legacy: `legacy-aspnet`, `wcf`, `workflow-foundation` |
| 26 | 3. Route cross-cutting work to the companion skill instead of keeping it inside generic `.NET` advice: |
| 27 | - project bootstrap or repo shape: `project-setup`, `architecture` |
| 28 | - frontend asset analysis in mixed `.NET` plus Node repos: `eslint`, `stylelint`, `htmlhint`, `webhint`, `biome`, `sonarjs`, `metalint`, `chous` |
| 29 | - code review: `code-review` |
| 30 | - language features: `modern-csharp` |
| 31 | - testing: `tunit`, `xunit`, `mstest` |
| 32 | - format, analyzers, coverage, and CI: `format`, `code-analysis`, `quality-ci`, `coverlet`, `reportgenerator` |
| 33 | - maintainability and architecture rules: `complexity`, `netarchtest`, `archunitnet` |
| 34 | 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. |
| 35 | 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. |
| 36 | 6. After code changes, validate with the repository's actual build, test, and quality workflow instead of generic `.NET` commands. |
| 37 | |
| 38 | ## Current Upstream Notes |
| 39 | |
| 40 | - `.NET 10.0.10` runtime and ASP.NET Core releases are servicing updates. Re-test affected paths such as heavily pinned GC heaps, NativeAOT, macOS drive enumeration, cookie-auth return URLs, data-protection cold starts, Blazor disposal/virtualization, and OpenAPI generation rather than changing architecture by default. |
| 41 | - `.NET SDK 10.0.302` is the current 10.0.3xx servicing SDK and enables the file-based app `#:include` / `#:exclude` flow without feature flags. `.NET SDK 8.0.423` remains an 8.0 servicing SDK; do not infer C# 13 or C# 14 availability from that line. |
| 42 | - The July 2026 "Build apps with .NET" Learn refresh remains broad routing context across web, cloud, desktop, mobile, AI, and console workloads; hand off to `project-setup`, `worker-services`, `aspnet-core`, `modern-csharp`, or another narrow skill as soon as the app model is known. |
| 43 | |
| 44 | ## Routing Heuristics |
| 45 | |
| 46 | - If the repo contains `Microsoft.NET.Sdk.Web`, start from a web skill, not generic `.NET`. |
| 47 | - If the repo contains Blazor, Razor Components, or `.razor` pages, prefer `blazor`. |
| 48 | - 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`. |
| 49 | - If the repo contains Orleans grains or silo hosting, prefer `orleans`. |
| 50 | - If the repo is mostly analyzers, CI, or coverage work, prefer the quality skill directly. |
| 51 | - If the user asks about “which skill should I use?”, answer with the narrowest matching skill and explain why in one short sentence. |
| 52 | - If no narrower skill matches, keep the work here and stay explicit about the missing specialization. |
| 53 | |
| 54 | ## Deliver |
| 55 | |
| 56 | - the correct specialized skill choice for the task |
| 57 | - repo-compatible code or documentation changes that stay aligned with the detected stack |
| 58 | - validation evidence that matches the real project runner and quality toolchain |
| 59 | |
| 60 | ## Validate |
| 61 | |
| 62 | - the chosen downstream skill actually exists in the catalog |
| 63 | - platform assumptions match proj |