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.
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
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
Route to the narrowest platform skill as soon as the stack is known:
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
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
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.
Do not stop at this skill once a narrower match exists. This skill should classify and hand off, not become a generic dumping ground.
After code changes, validate with the repository's actual build, test, and quality workflow instead of generic .NET commands.
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.
