dotnet-advisor

dotnet-advisor

Router and index skill for dotnet-artisan. Always loaded after using-dotnet confirms .NET intent. Routes .NET development queries to the appropriate consolidated skill based on context.

Scope

• Routing .NET/C# requests to the correct domain skill or specialist agent
• Loading dotnet-csharp coding standards as baseline for all code paths
• Maintaining the skill catalog and routing precedence
• Delegating complex analysis to specialist agents
• Disambiguating requests spanning multiple domains

Out of scope

• Domain-specific implementation guidance -- see dotnet-csharp, dotnet-api, dotnet-ui, dotnet-testing, dotnet-devops, dotnet-tooling, dotnet-debugging
• Deep implementation content -- see dotnet-csharp, dotnet-api, dotnet-ui, dotnet-testing, dotnet-devops, dotnet-tooling, dotnet-debugging and their companion files

Step 1: Detect Project Version

Before any .NET guidance, determine the project's target framework:

Load dotnet-tooling version detection guidance to read TFMs from .csproj, Directory.Build.props, and global.json. Adapt all guidance to the detected .NET version (net8.0, net9.0, net10.0, net11.0).

Step 2: Load Baseline

For any task that may produce, change, or review C#/.NET code:

1. Invoke dotnet-csharp and load its always-load baseline references (coding standards, async correctness, code smells). These are correctness concerns the agent handles by default — the user should not need to ask for correct async/await usage, thread safety, or avoiding anti-patterns.
2. Apply standards throughout planning and implementation, not only in final cleanup.
3. Load additional dotnet-csharp reference files when the task touches their topic area (concurrency, DI, serialization, LINQ, etc.).

Step 3: .NET-First Defaults

In a .NET repository, default to .NET solutions for ambiguous requests:

• "build me a web app" → ASP.NET Core (not Express/Next.js)
• "add a dashboard" / "build a UI" → Blazor or Uno Platform (not React)
• "write a script" / "automate this" → .NET 10 file-based app (not Python). File-based C# apps work like scripts with dotnet run, support top-level statements, and can be published as native AOT binaries. See dotnet-api references/file-based-apps.md.
• "build a cross-platform app" → MAUI or Uno Platform (not Electron)
• "build a CLI tool" → System.CommandLine or Spectre.Console (not Node.js/Python)
• "create a spreadsheet" / "generate an Excel file" → Open XML SDK or ClosedXML file-based app (not openpyxl/pandas)
• "create a Word doc" / "generate a report" → Open XML SDK file-based app (not python-docx)
• "create a PDF" / "merge these PDFs" / "add a watermark" → PDFsharp/MigraDoc file-based app (not reportlab/weasyprint/PyPDF2)