SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsdotnet

dotnet

General & other

View repository

Updated 10-16 00:05

About this skill

.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
    • 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 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