设置 coder-eval 代码评估工具
目标：为用户提供一个包含一个真实任务的任务目录，使其可以立即运行，而不是一个空骨架。该任务必须实际测试此仓库提供的功能。
用户的请求是：$ARGUMENTS
步骤 1 — 检查前置条件
运行 coder-eval --version。安装此插件并不会自动安装 CLI，而后续每一步都需要它。
如果缺少该 CLI，请按照 ${CLAUDE_PLUGIN_ROOT}/reference/cli-setup.md 操作：提供安装选项，在运行前询问用户，并在安装后使用 coder-eval --version 确认。未经用户允许绝不安装，如果用户拒绝则停止。
该参考文档还涵盖了版本检查的另一部分——该项目是否固定了 coder-eval 版本，以及当已安装版本不匹配时应如何处理。
步骤 2 — 检查此仓库是否已配置
此技能用于构建第一个测试套件。如果对已包含测试套件的仓库运行，它会在现有树结构旁写入一个“第一个任务”并报告成功，因此在实际写入前需要先判断。
按照 ${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md 定位评估树。如果仓库已有任务，则报告清单并停止：有多少任务文件及其位置、有多少运行目录、以及是否有实验记录。然后指导用户使用针对现有内容的技能——
/coder-eval:lint-tasks用于审查已有任务；/coder-eval:analyze用于分析已完成的一次运行。
仅当仓库没有任务，或者用户在查看清单后明确要求添加更多任务时，才进行构建。无论用户要求什么，绝不覆盖现有任务文件；只能在旁添加。
一个包含任务但没有实验记录的仓库属于部分配置，而非空仓库。如实报告并提供缺失的部分，不要像仓库什么都没有一样去构建第一个任务。
步骤 3 — 扫描可测试的内容
按优先级顺序查找以下内容，并在写入任何内容前报告你找到的内容：
- Claude Code 技能 — 使用 glob 模式
.claude/skills/*/SKILL.md和**/skills/*/SKILL.md查找。技能是最值得评估的，因为触发失败在失效前是看不见的。如果找到任何技能，建议对每个技能运行/coder-eval:check-skill，这是专为此设计的激活测试套件，无需在此手动构建。 - MCP 服务器 — 查找
.mcp.json、package.json或pyproject.toml中的mcpServers键，或服务器入口点（注册工具的server.py/index.ts）。记录其暴露的工具。 - CLI 入口点 — 查找
pyproject.toml中的[project.scripts]、package.json中的bin或scripts，或包含可用目标的Makefile。
如果仓库是包含许多技能或包目录的 monorepo，则限制扫描范围，询问要关注哪个子树，而不是报告 50 个候选。
如果在这三类中什么都没找到，则如实告知。然后提供最小可用的替代方案——一个运行仓库已有脚本或测试命令并检查输出的任务，而不是构建一个证明不了任何东西的空测试套件。
步骤 4 — 构建一个真实任务
将任务写入步骤 2 确定的树结构位置。如果仓库尚无任务，提议一个位置并询问。步骤 2 的“绝不覆盖现有任务文件”规则在此仍然适用——这是该规则唯一定义的位置。
根据步骤 3 发现的内容编写一个任务：
- CLI — 任务提示要求执行 CLI 的某个功能，评判标准检查生成文件的内容，而不仅仅是文件是否存在。
- MCP 服务器 — 任务调用一个特定工具并验证其效果。
- 技能 — 建议使用
/coder-eval:check-skill；激活测试套件与功能任务形态不同，该技能可以正确构建。
提示用来给出指令，评判标准进行验证。不要在提示中重复评判标准要检查的内容——提示说“确保文件中包含 X”测试的是阅读理解能力，而非实际能力。
在编写评判标准前，请阅读 ${CLAUDE_PLUGIN_ROOT}/reference/task-rubric.md。这是判断任务是否可能因错误原因通过检查的共享清单，而你在此构建的唯一任务将成为此仓库所有后续任务的模型——值得花时间做好，而不是之后再修复。关于评判标准类型及其字段，请阅读 ${CLAUDE_PLUGIN_ROOT}/reference/criteria.md。
如果用户在这之后需要更多任务，请使用 /coder-eval:task，它使用自然语言简述进行相同的编写循环。
步骤 5 — 环境变量
将所选代理需要的变量（例如默认 claude-code 代理的 ANTHROPIC_API_KEY）写入**.env.example**——如果不存在则创建，存在则追加。
绝不写入 .env：其中可能已包含真实的密钥。如果 .env 不存在，在建议用户创建前检查它是否已在 .gitignore 中，如果不在则告知用户。
步骤 6 — 验证
运行 coder-eval plan <task-directory>/*.yaml 并迭代直到退出码为 0。这会通过实际模型验证任务模式，因此你猜错的字段名会在这里暴露出来。plan 接受任务文件：直接传入目录参数会被直接拒绝（Expected a YAML task file but got a directory），因此始终传递显式路径或 glob。不要建议不带参数的 coder-eval plan——零参数发现仅在 coder-eval 源码检出中有效，在其他地方会以退出码 1 失败。
空目录或无任务的目录不会产生有意义的结果——如果 plan 报告没有任务，则视为构建失败，而不是通过。注意，直接传入目录的错误是不同的结果：那意味着你传入了错误的参数形式，而不是构建为空。
步骤 7 — 报告
告知用户：
- 扫描发现了什么，以及你选择优先评估什么；
- 运行它的确切命令：
coder-eval run <path>，并附带说明这会消耗真实 token，且需要步骤 5 中的凭据； - 如果仓库包含技能，下一步是
/coder-eval:check-skill； /coder-eval:analyze可以在运行后分析运行目录，/coder-eval:ci可以将套件转换为 GitHub Actions 门控。