/dotnet

name: dotnet
description: "Primary 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, debugging, review, or refactoring; routing to framework and tooling skills. DO NOT USE FOR: unrelated stacks; tasks already covered by a narrower .NET skill. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made."
compatibility: "Requires a .NET repository, solution, or project tree."

.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`, or architecture guidance in [building AI agents with .NET](https://managed-code.com/blog-post/building-ai-agents-with-csharp-dotnet)
• 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.

Test Output Budget

• Keep native runner progress and ANSI enabled (`--progress on --ansi on` for supported MTP/TUnit runners); use a PTY locally. Do not replay progress redraws into model context. Use the detected runner's flags, not MTP switches on VSTest.
• Show warnings and errors plus one final summary (counts, duration, exit code). Configure test-owned console logging at `Warning`; keep Information/Debug/Trace, successful-test output, and expected negative-test noise out of context. Quiet build verbosity alone does not filter application logs.
• On failure, crash, startup error, or timeout, show the failing test/resource, root exception, and relevant stack frames. Deduplicate; cap each diagnostic tool response at 80 lines / 8 KiB, whichever comes first. Never automatically dump stdout/stderr, host logs, browser console history, DOM/HTML, TRX, or crash artifacts.
• Keep necessary diagnostics in size-bounded or rotating artifacts and link them. Search by exact failure/correlation; read bounded excerpts, never whole logs. Capture/filter noisy output before tool delivery, preserve the real exit code, and disclose truncation. Monitor actual activity; silence alone does not prove a hang.

Current Upstream Notes

• `.NET 10.0.11` runtime and ASP.NET Core releases are servicing updates. Re-test affected paths such as cgroup-v2 memory limits, Mono native-library resolution, Windows directory enumeration, WASM AOT/lazy-load startup, thread-static initialization, Blazor persisted circuits, and OpenAPI generation rather than changing architecture by default.
• `.NET SDK 10.0.400` is the current 10.0.4xx feature band. It expands file-based app support, adds Microsoft.Testing.Platform project/solution selection to `dotnet test`, accepts `@` as the `dotnet new` option separator, and includes hardlink and up-to-date build fixes. Keep `global.json`, workloads, and CI images aligned before adopting the new band.
• The August 2026 "Build apps with .NET" Learn overview 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.

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 expl