本技能是 plan-and-build 的伴随版本，运行相同的流程链，仅替换为 .NET 解决方案与 Azure DevOps 跟踪器的绑定：参数 → 1 探索（扇出）→ 2 起草计划 → 3 对抗式评审（三视角扇出）→ 4 人工检查点（计划模式）→ 5 实现（测试先行，仅在文件互不重叠时扇出）→ 6 门禁（红色绝不继续）→ 7 提交 → 8 闭环。阶段间停止、扇出判断（读/评并行、写串行）与 RED→GREEN 循环与母技能一致。
参数解析顺序：Azure Boards 工作项（纯数字、#2 或工作项 URL，用 wit_get_work_item 获取，读取 System.Title、Description、State、WorkItemType、Tags，并用 wit_list_work_item_comments 看讨论）；然后是存在的 .md 简介文件路径；其余视为行内描述。基本流程的 Issue 类型无验收条件字段，仅 Agile/Scrum 类型定义 AcceptanceCriteria，不应假设其存在。Description 与验收条件返回 HTML，需先转为文本。获取失败要原样报错停止，描述为空要询问。
探索阶段按整洁架构分层，每层一个探索子代理：Domain、Application、Persistence、Api；约定优先取自 docs/dotnet.md 与 AGENTS.md，否则从代码推断，需实际核对而非假设。计划每一步以 dotnet test --filter <Name> 和/或 linter 作为验证，首步为失败测试。多条验收条件通常是同一服务方法中的多个守卫子句加同一测试类中的多个测试，应保持串行编辑。迁移用 make migrate name=<Name> 再 make db-update，或 dotnet ef migrations add 加 dotnet ef database update，不假设启动时自动运行。
门禁运行仓库的完整检查（通常为 make check，含 lint、警告即错误构建、测试及架构测试），再对 diff 运行 /code-review，需自行运行并粘贴真实输出。提交时若来自工作项，需在提交信息中包含 AB#<id> 令牌（如 AB#2）以关联 Azure Boards。除非用户要求，否则不要推送或开 PR。使用工作项路径需在 .mcp.json 配置 azure-devops MCP 服务器；若 wit_* 返回身份未物化错误，应改用 --authentication pat，读取 PERSONAL_ACCESS_TOKEN，需工作项读取范围，仅 git 的 PAT 会导致 401。其余内容与 plan-and-build 一致，如扇出纪律、RED→GREEN 与密钥卫生。