Build Evals 用于为 /build-tools 创建的 MCP 工具集合生成 LLM 评测测试。该技能读取 .discover.json 与已有工具文件，然后逐个集合在 tests/evals/ 下构建评测测试文件。
重要限制：本技能仅在 tests/evals/ 内创建文件——setup 文件与评测测试文件。不会创建或修改工具文件、集合索引、集成测试、mock handler 或其他任何文件。
与集成测试（/build-tools-tests）的关键区别：
- 集成测试：每个工具一个文件，直接针对真实 API 测试 handler，确定性。
- 评测测试：按工作流对相关工具分组，通过 Claude Agent SDK 测试，概率性，需先运行 npm run build（针对 dist/ 运行）。
前置条件：
- 已运行 /build-tools（工具集合存在于 src/umbraco-api/tools/）
- 项目可构建：npm run build
- 具备 LLM API 密钥（评测测试使用 Claude Agent SDK——可用 Claude Code 订阅或 ANTHROPIC_API_KEY）
参数：
- 无参数：为 .discover.json 中的所有集合构建评测
- 单个集合名：仅为该集合构建评测（例如 /build-evals form）
代理： 该技能编排以下代理，用于相关步骤：
- eval-test-creator：创建评测测试文件（Step 5）
关键规则：
- 先构建再运行。评测测试针对 dist/index.js 运行，务必先 npm run build。
- 一次只处理一个集合。完成一个集合后再开始下一个。
- 按工作流对工具分组。与集成测试不同，评测测试把相关工具分组为工作流场景。一个含 5 个工具的工具集可能只有 1-2 个评测测试文件。
- 迭代提示词。评测测试是概率性的。测试失败时，修复通常在提示词——让指令更明确、为 ID 增加搜索步骤、使用唯一标识符。
- 开发期保持 verbose。创建/调试时始终设置 verbose: true。测试稳定通过后再关闭。
- 分开运行命令。始终把 build 与 test 作为独立的 Bash 调用，不要用 && 链接。
工作流（逐个集合处理，完成一个再开始下一个）：
Step 0：读取发现清单。读取项目根目录的 .discover.json（包含 apiName、swaggerUrl、baseUrl、collections 等字段）。如提供了参数则过滤到该集合。若 .discover.json 不存在，提示用户先运行 npx @umbraco-cms/create-umbraco-mcp-server discover。
Step 1：检查前置条件。对每个集合验证 src/umbraco-api/tools/{collection}/index.ts 是否存在，不存在则跳过并提示运行 /build-tools；检查是否已有评测测试（查找 tests/evals/{collection}-*.test.ts 文件），已存在则跳过。然后确保评测 setup 存在且项目可构建：若 tests/evals/helpers/e2e-setup.ts 不存在则创建；若 tests/evals/jest.config.ts 不存在则创建；npm run build。先修复构建错误。
Step 2：读取工具文件。读取集合的 index.ts 获取工具列表与集合元数据，以及每个工具文件，理解工具名、输入 schema、描述、slices（read、list、create、update、delete、search 等），从而确定要创建哪些工作流场景。
Step 3：创建评测 setup（如不存在）。评测测试使用 tests/evals/ 下的集中式 setup。仅在这些文件不存在时创建。jest.config.ts 使用 ts-jest ESM 预设、node 测试环境、rootDir 为 ../..、testMatch 指向 tests/evals/**/*.test.ts、setupFilesAfterEnv 指向 e2e-setup.ts、maxConcurrency 与 maxWorkers 为 1、testTimeout 120000 等。e2e-setup.ts 检测 API 模式：若 src/mocks/ 存在 handler 文件则使用 mock API 设置 USE_MOCK_API: "true"；否则使用 .env 凭据配置真实 API。关键规则包括：用 process.cwd() 解析 dist/index.js；从 package.json 的 name 字段或 src/index.ts 获取 mcpServerName；设置 DISABLE_MCP_CHAINING: "true" 以避免测试期间连接链式服务器；使用保守默认值（Haiku 模型、10 轮、$0.25 预算、60 秒超时）。该文件通过 setupFilesAfterEnv 自动加载，测试文件无需导入。同时确保 package.json 中 test:evals 脚本使用专用配置。
Step 4：设计评测场景。根据集合中可用工具设计 1-2 个工作流场景：CRUD 生命周期（存在 create + list/get + update + delete 时，测试完整增删改查周期）、只读工作流（仅有 get/list/search 时）、搜索工作流（存在 search + get 时）、层级工作流（存在 folder/tree 工具时）。每个集合目标 1-2 个场景。
Step 5：创建评测测试文件。使用 eval-test-creator 代理。每个工作流场景在 tests/evals/ 下创建一个文件：tests/evals/{collection}-{workflow}.test.ts。命名约定：CRUD 生命周期为 {collection}-crud.test.ts，只读为 {collection}-read.test.ts，搜索为 {collection}-search.test.ts，层级为 {collection}-hierarchy.test.ts。测试文件使用 @jest/globals，并从 @umbraco-cms/mcp-server-sdk/evals 导入 runScenarioTest、setupConsoleMock、getDefaultTimeoutMs。定义 COLLECTION_TOOLS 常量，并在 describe 中调用 setupConsoleMock、获取默认超时、使用 runScenarioTest 传入 prompt、tools、requiredTools、successPattern、verbose 等。注意无需导入 setup——e2e-setup.ts 会自动加载。
提示词编写规则：编号步骤、使用唯一标识符（时间戳避免碰撞）、动态搜索 ID（不要硬编码）、末尾设置成功短语、明确说明、使用实际工具名。创建后执行 npm run compile，修复错误。
Step 6：构建并运行。先 npm run build，再运行该集合的评测测试 npm run test:evals -- --testPathPatterns="{collection}"。若测试失败：检查构建输出是否生成 dist/index.js、查看 verbose 输出、常见修复（工具未找到检查名称是否完全匹配、LLM 忽略指令使提示词更明确、超时增加 defaultMaxTurns 或简化提示词、预算超限简化工作流或增加 defaultMaxBudgetUsd、create 返回 void 则在 create 后加搜索/列表步骤找 ID）。更新提示词并重跑，测试失败时不要进入下一个集合。
Step 7：下一个集合。对 .discover.json 中下一个集合重复 step 1-6。
Step 8：最终验证。所有集合都有评测测试后，npm run build 与 npm run test:evals，然后运行 /count-mcp-tools 确认所有集合在 Evals 列显示 yes，报告生成内容（有评测测试的集合数、每集合评测测试文件数、测试的工作流类型、跳过的集合、需要关注的测试失败）。
文件结构：运行后评测测试目录应包含 jest.config.ts、helpers/e2e-setup.ts、各集合的 -crud/-read 等测试文件。
后续步骤：评测测试通过后，可关闭测试文件中的 verbose: true 以获得更干净的 CI 输出；运行 /mcp-testing 参考高级评测模式；利用评测反馈改进工具描述与 schema。