.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

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

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

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

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

1. 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.
2. Do not stop at this skill once a narrower match exists. This skill should classify and hand off, not become a generic dumping ground.
3. After code changes, validate with the repository's actual build, test, and quality workflow instead of generic .NET commands.

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

Related skills

Related agents