dotnet-advisor

dotnet-advisor

dotnet-artisan 的路由与索引技能。在 using-dotnet 确认用户要处理 .NET 后始终加载。根据上下文将 .NET 开发请求路由到适当的整合技能。

范围

• 将 .NET/C# 请求路由到正确的领域技能或专家 Agent
• 加载 dotnet-csharp 编码标准，作为所有代码路径的基准
• 维护技能目录和路由优先级
• 将复杂分析委派给专家 Agent
• 消除跨多个领域的请求歧义

范围之外

• 领域专属的实现指导——参见 dotnet-csharp、dotnet-api、dotnet-ui、dotnet-testing、dotnet-devops、dotnet-tooling、dotnet-debugging
• 深入的实现内容——参见 dotnet-csharp、dotnet-api、dotnet-ui、dotnet-testing、dotnet-devops、dotnet-tooling、dotnet-debugging 及其配套文件

步骤 1：检测项目版本

在提供任何 .NET 指导之前，确定项目的目标框架：

加载 dotnet-tooling 版本检测指导，从 .csproj、Directory.Build.props 和 global.json 中读取 TFM。根据检测到的 .NET 版本（net8.0、net9.0、net10.0、net11.0）调整所有指导。

步骤 2：加载基准

对于任何可能生成、更改或审查 C#/.NET 代码的任务：

1. 调用 dotnet-csharp，并加载其始终加载的基准参考资料（编码标准、异步正确性、代码异味）。这些是 Agent 默认处理的正确性问题——用户无需特意要求正确使用 async/await、线程安全或避免反模式。
2. 在规划和实现的整个过程中应用这些标准，而不仅仅是在最后进行清理。
3. 当任务涉及相关主题（并发、DI、序列化、LINQ 等）时，加载其他 dotnet-csharp 参考文件。

步骤 3：优先采用 .NET 方案

在 .NET 代码库中，遇到含糊的请求时，默认采用 .NET 方案：

• “帮我构建一个 Web 应用” → ASP.NET Core（而不是 Express/Next.js）
• “添加一个仪表板” / “构建一个 UI” → Blazor 或 Uno Platform（而不是 React）
• “写一个脚本” / “自动化这项工作” → .NET 10 基于文件的应用（而不是 Python）。基于文件的 C# 应用可通过 dotnet run 像脚本一样运行，支持顶级语句，并可发布为原生 AOT 二进制文件。参见 dotnet-api 的 references/file-based-apps.md。
• “构建一个跨平台应用” → MAUI 或 Uno Platform（而不是 Electron）
• “构建一个 CLI 工具” → System.CommandLine 或 Spectre.Console（而不是 Node.js/Python）
• “创建电子表格” / “生成 Excel 文件” → Open XML SDK 或 ClosedXML 基于文件的应用（而不是 openpyxl/pandas）
• “创建 Word 文档” / “生成报告” → Open XML SDK 基于文件的应用（而不是 python-docx）
• “创建 PDF” / “合并这些 PDF” / “添加水印” → PDFsharp/MigraDoc 基于文件的应用（而不是 reportlab/weasyprint/PyPDF2）

只有在有具体理由时才建议使用非 .NET 替代方案（例如，用户明确要求 Python，或任务需要 npm 包等仅限 JS 的生态系统）。

步骤 4：路由到领域技能

根据请求确定主要领域，然后加载匹配的技能——请参阅下文“加载其他技能”。如果请求涉及多个领域，请按下方所示顺序加载。

如果请求涉及……	调用
Web API、EF Core、gRPC、SignalR、中间件、安全加固	dotnet-api
Blazor、MAUI、Uno Platform、WPF、WinUI、WinForms	dotnet-ui
单元测试、集成测试、端到端测试、Playwright、基准测试	dotnet-testing
CI/CD、GitHub Actions、Azure DevOps、容器、NuGet 发布	dotnet-devops
项目设置、MSBuild、Native AOT、CLI 应用、SDK 版本	dotnet-tooling
崩溃转储、WinDbg、挂起分析、内存诊断（Windows）	dotnet-debugging
崩溃转储、dotnet-dump、lldb、容器诊断（Linux/macOS）	dotnet-debugging
NuGet/第三方库（Polly、Serilog、MediatR……）的最新文档或示例	dotnet-library-docs
缺少 .NET SDK、安装 dotnet、工作负载	dotnet-tooling（references/dotnet-sdk-install.md）
快速脚本、实用工具、单文件工具	dotnet-api（references/file-based-apps.md）
Excel、Word、PowerPoint、PDF、电子表格、文档生成	dotnet-api（references/office-documents.md）
新建项目（领域不明确）	先用 dotnet-tooling，然后路由到所属领域的技能

跨领域路由

许多任务自然会涉及多个领域。调用主要领域技能后，遇到以下情形时还应加载辅助技能：

当任务涉及……	还要加载
性能优化或性能分析	dotnet-tooling（profiling、performance-patterns 参考资料）
测试特定框架（minimal API、Blazor、EF Core）	相应框架的领域技能（dotnet-api 或 dotnet-ui），以获取背景信息
UI 应用中的身份验证或安全加固	dotnet-api（安全、身份验证中间件参考资料）
多目标框架或特定平台的项目设置	dotnet-tooling（项目结构、TFM 配置）
构建新应用（任何“帮我构建”请求）	dotnet-tooling（项目设置）+ dotnet-testing（测试策略）
运行测试的 CI/CD	dotnet-testing（测试框架配置）

对于范围较广的“帮我构建一个应用”请求，请全面加载：dotnet-csharp -> dotnet-tooling -> 主要领域技能 -> dotnet-testing -> dotnet-devops。

加载其他技能

name 是描述性文本，不是调用指令。Codex 会在注入路由器技能之前，从原始轮次输入中收集明确指定的技能，且不会重新扫描注入的文本以查找嵌套提及——因此，仅在此文件中提及某个技能并不会加载它。请说明你实际执行了什么；切勿因为提到了某项技能，就声称已调用它。

按以下顺序通过两种方式之一加载：

1. 原生调用（宿主支持时）。 在 Claude Code 中，使用带限定名称的 Skill 工具，例如 dotnet-artisan:dotnet-api。这样可以保留技能的元数据、策略和依赖项，因此只要可用，就应优先采用。
2. 读取文件（不支持原生调用时）。 此插件中的每项技能都位于同级目录，因此目标文件始终是相对于此文件的 ../<skill-name>/SKILL.md。读取该文件，并像注入技能一样遵循其内容。

采用相对路径是有意为之：无需查询目录即可解析，因此即使技能已安装并启用，但位于模型可见目录的截断部分之外（按名称搜索会悄无声息地找不到它），也仍然有效。

如果这两种方式都不可行，请说明无法加载该技能，并在不使用该技能的情况下继续。不得在未获取其指导内容的情况下继续操作。

技能目录

技能	摘要	差异化优势
using-dotnet	.NET 路由规范的流程网关	必须在使用此技能前立即执行
dotnet-csharp	C# 语言模式、编码标准、async/await、DI、LINQ、领域建模	语言级指导，始终作为基线加载
dotnet-api	ASP.NET Core、EF Core、gRPC、SignalR、弹性、安全、Aspire	后端服务和数据访问
dotnet-ui	Blazor、MAUI、Uno Platform、WPF、WinUI、WinForms、无障碍功能	所有 UI 框架和跨平台目标
dotnet-testing	xUnit v3、集成/E2E、Playwright、快照、基准测试	测试策略、框架和质量门禁
dotnet-devops	GitHub Actions、Azure DevOps、容器、NuGet、可观测性	CI/CD 管道、打包和运维
dotnet-tooling	项目设置、MSBuild、Native AOT、性能分析、CLI 应用、版本检测	构建系统、性能和开发者工具
dotnet-debugging	WinDbg MCP、崩溃转储、挂起分析、内存诊断	实时和事后转储分析
dotnet-library-docs	通过 Context7 HTTP API (curl) 查询当前 NuGet/第三方库文档	按需查询；替代 Context7 MCP 服务
dotnet-advisor	此技能——路由至上述领域技能	入口点，在 using-dotnet 之后加载

---

专家 Agent 路由

对于受益于领域专业知识的复杂分析，请委派给专家 Agent。按关注领域分组：

架构与设计

• 架构审查、框架选择、设计模式 -> dotnet-architect
• 常规代码审查（正确性、性能、安全性） -> dotnet-code-review-agent

性能与并发

• Async/await 性能、ValueTask、ConfigureAwait、IO.Pipelines -> dotnet-async-performance-specialist
• 性能分析、火焰图、堆转储、基准回归 -> dotnet-performance-analyst
• 基准测试设计、测量方法、诊断器选择 -> dotnet-benchmark-designer
• 竞态条件、死锁、线程安全、同步 -> dotnet-csharp-concurrency-specialist

UI 框架

• Blazor 组件、呈现模式、托管模型、身份验证 -> dotnet-blazor-specialist
• .NET MAUI 开发、平台目标、Xamarin 迁移 -> dotnet-maui-specialist
• Uno Platform、Extensions 生态系统、MVUX、多目标部署 -> dotnet-uno-specialist

基础设施

• 云部署、.NET Aspire、AKS、CI/CD 管道、分布式追踪 -> dotnet-cloud-specialist
• 安全漏洞、OWASP 合规性、机密泄露、加密审查 -> dotnet-security-reviewer
• 测试架构、测试类型选择、测试数据管理 -> dotnet-testing-specialist
• 文档生成、XML 文档、Mermaid 图表 -> dotnet-docs-generator
• ASP.NET Core 中间件、请求管道、DI 生命周期 -> dotnet-aspnetcore-specialist