skill-creator

技能创建器

用于创建新技能并对其进行迭代改进的技能。

从整体上看，创建技能的流程如下：

• 确定你希望技能实现什么，以及大致应如何实现
• 编写技能草稿
• 创建几个测试提示词，并在加载该技能的情况下运行 Agent
• 帮助用户从定性和定量两个方面评估结果
  • 在测试于后台运行期间，如果还没有定量评估，就起草一些；如果已有评估，可以直接使用，也可以在认为有必要时进行修改。然后向用户说明这些评估（如果已有评估，则说明现有评估）
  • 使用 eval-viewer/generate_review.py 脚本向用户展示结果，供其查看，同时也让他们查看定量指标
• 根据用户对结果的评估反馈重写技能（如果定量基准中显现出明显缺陷，也要据此改进）
• 重复上述流程，直到满意为止
• 扩展测试集，并进行更大规模的测试

使用此技能时，你的任务是弄清用户处于流程的哪个阶段，然后介入并帮助他们推进。例如，他们可能会说：“我想为 X 创建一项技能。”你可以帮助他们明确需求、编写草稿、编写测试用例、确定评估方式、运行所有提示词并重复迭代。

另一方面，他们可能已经有了技能草稿。这种情况下，你可以直接进入评估和迭代环节。

当然，你始终应保持灵活。如果用户说：“我不需要做一堆评估，咱们随便聊聊就行”，那就照做。

技能完成后（不过流程顺序可以灵活调整），你还可以运行技能描述优化器来优化技能的触发方式。我们为此专门准备了另一个脚本。

明白了吗？好。

与用户沟通

技能创建器的用户对编程术语的熟悉程度各不相同，有些人第一次打开终端，有些则是经验丰富的开发者；大多数人对计算机都相当熟悉。

因此，请留意上下文线索，判断该如何措辞！默认情况下，可以参考以下建议：

• “评估”和“基准测试”这类术语一般可以使用
• 对于“JSON”和“断言”，除非用户给出明确线索，表明他们了解这些概念，否则应避免直接使用而不加解释

如果你不确定，可以简要解释术语；如果不确定用户是否能理解，也可以用简短定义加以说明。

---

创建技能

明确意图

首先了解用户的意图。当前对话中可能已经包含了用户希望固化为技能的工作流（例如，他们说“把这个变成一项技能”）。如果是这样，请先从对话历史中提取相关信息，包括使用的工具、步骤顺序、用户提出的修正，以及观察到的输入／输出格式。用户可能需要补充缺失的信息，并应在继续下一步之前予以确认。

1. 这项技能应让 Agent 能够做什么？
2. 这项技能应在何时触发？（哪些用户措辞或上下文）
3. 预期的输出格式是什么？
4. 是否应设置测试用例来验证技能是否有效？对于输出可客观验证的技能（文件转换、数据提取、代码生成、固定工作流步骤），测试用例通常很有帮助。对于输出主观性较强的技能（写作风格、艺术创作），通常不需要。根据技能类型提出合适的默认建议，同时让用户决定。

访谈与调研

主动询问边界情况、输入/输出格式、示例文件、成功标准和依赖项。彻底理清这些内容后，再开始编写测试提示词。

检查可用的 MCP；如果有助于调研（搜索文档、寻找类似技能、查找最佳实践），且有可用的子 Agent，就并行调研；否则直接调研。提前准备好相关背景信息，减轻用户的负担。

编写 SKILL.md

根据用户访谈，填写以下部分：

• name：技能标识符
• description：何时触发，以及技能的作用。这是主要的触发机制，应同时说明技能的作用和适用的具体场景。所有“何时使用”的信息都放在这里，不要放在正文中。注意：AI Agent 往往会“触发不足”——明明技能有用，却没有使用。为避免这一点，请让技能描述稍微“主动”一些。例如，与其写“如何构建简单快速的仪表板来展示内部数据”，不如写“如何构建简单快速的仪表板来展示内部数据。只要用户提到仪表板、数据可视化、内部指标，或希望展示任何类型的公司数据，即使没有明确要求创建‘仪表板’，也务必使用此技能。”
• compatibility：所需工具和依赖项（可选，很少需要）
• 其余技能内容 :)

技能编写指南

技能结构

skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description required)
│   └── Markdown instructions
└── Bundled Resources (optional)
    ├── scripts/     - Executable code for deterministic/repetitive tasks
    ├── references/  - Docs loaded into context as needed
    ├── resources/   - Alternate resource folder used by some hosts
    └── assets/      - Files used in output (templates, icons, fonts)

渐进式披露

技能采用三级加载系统：

1. 元数据（name + description）——始终位于上下文中（约 100 个单词）
2. SKILL.md 正文——技能触发时加载到上下文中（理想情况下少于 500 行）
3. 打包资源——按需加载（不限量，脚本可在不加载的情况下执行）

这些字数只是估算；如有需要，可以适当增加。

关键模式：

• 将 SKILL.md 控制在 500 行以内；如果快要达到上限，就增加一层层级结构，并清楚说明模型接下来应前往何处查看。
• 在 SKILL.md 中清晰地引用文件，并说明何时阅读这些文件
• 对于较大的参考文件（超过 300 行），应添加目录

领域组织：当技能支持多个领域/框架时，按变体组织：

cloud-deploy/
├── SKILL.md (workflow + selection)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

Agent 只读取相关的参考文件。

跨平台 Frontmatter

将可移植性视为一个分层系统：

1. 可移植基线：包含 SKILL.md、YAML frontmatter 和 Markdown 指令的技能目录。
2. 主机专用扩展：用于改进与特定运行时集成的额外字段或文件。

可移植基线始终为：

---
name: my-skill
description: What this skill does and when to trigger it.
---

确保此基线本身可以正常使用。不要将关键行为仅定义在主机专用扩展中。

仅在目标运行时能够从中受益时才使用扩展：

扩展	主机	说明
agents/openai.yaml	Codex CLI / Codex app	记录 Codex 专用元数据及 UI/调用提示
allowed-tools	运行时专用兼容性字段	在某些 Codex/OpenClaw 环境中有用，但不是可移植基线的一部分
compatibility	面向 Claude 的生态系统	工具/MCP 依赖说明；保持为可选项
user-invocable、disable-model-invocation、command-*、requires.*、os、primaryEnv	OpenClaw	主机专用的命令和资格控制
context: fork、钩子、动态上下文注入、自定义 Agent 字段	Claude Code	仅适用于 Claude Code 的扩展；切勿假设其他主机也支持

Codex 扩展示例（agents/openai.yaml）：

allow_implicit_invocation: true
interface:
  display_name: My Skill

OpenClaw 扩展示例（主机专用字段）：

---
name: my-skill
description: ...
user-invocable: true
disable-model-invocation: false
metadata:
  openclaw:
    requires:
      bins: ["curl"]
    primaryEnv: OPENAI_API_KEY
---

**重要的兼容性规则：**如果要编写通用技能，请从可移植基线开始，仅当用户明确指定支持相关扩展的主机时，才添加扩展。

避免意外原则

这不言而喻，但技能不得包含恶意软件、漏洞利用代码或任何可能危及系统安全的内容。如果描述技能的意图，技能内容不应让用户感到意外。不要配合创建具有误导性，或旨在协助未经授权访问、数据外泄或其他恶意活动的技能。不过，像“扮演某个 XYZ”这样的内容是可以的。

写作模式

指令中优先使用祈使句。

定义输出格式——可以这样写：

## Report structure
Use this template for the report:
# [Title]
## Executive summary
## Key findings
## Recommendations

示例模式——加入示例很有用。你可以这样编排（但如果示例中出现“输入”和“输出”，你可能需要稍作调整）：

## Commit message format
**Example 1:**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication

写作风格

尽量向模型解释事情为何重要，而不是用生硬、强硬的“必须”要求。运用心智理论，并尽量让技能具有通用性，而不要局限于特定示例。先写一份草稿，再以全新的视角审阅并改进。

测试用例

写完技能草稿后，构思 2-3 个真实的测试提示词——就像真实用户会说的那样。与用户分享：“这里有几个我想尝试的测试用例。你觉得合适吗？还是想再添加一些？”（不一定要使用这句原话。）然后运行测试。

将测试用例保存到 evals/evals.json。暂时不要编写断言，只写提示词。运行期间，你会在下一步起草断言。

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "User's task prompt",
      "expected_output": "Description of expected result",
      "files": []
    }
  ]
}

完整架构请参阅 references/schemas.md（其中包含稍后要添加的 assertions 字段）。

运行和评估测试用例

本节是一段连续流程：请一直执行到最后，因为只有运行完成时才能采集计时数据。请按照以下步骤运行评估，不要使用单独的技能测试技能或走捷径。

将结果放在 <skill-name>-workspace/ 中，与技能目录并列。在工作区内，按迭代组织结果（iteration-1/、iteration-2/ 等），然后在每个迭代目录中，为每个测试用例创建一个目录（eval-0/、eval-1/ 等）。不要预先创建所有目录——随着流程推进逐步创建即可。

步骤 1：在同一轮中启动所有运行（使用技能和基线）

针对每个测试用例，在同一轮中启动两个子 Agent——一个使用技能，一个不使用。这一点很重要：不要先启动使用技能的运行，之后再回来运行基线。一次性启动所有任务，让它们在大致相同的时间完成。

使用技能的运行：

Execute this task:
- Skill path: <path-to-skill>
- Task: <eval prompt>
- Input files: <eval files if any, or "none">
- Save outputs to: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Outputs to save: <what the user cares about — e.g., "the .docx file", "the final CSV">

基线运行（使用相同提示词，但基线取决于上下文）：

• 创建新技能：不使用任何技能。使用相同提示词，不提供技能路径，并保存到 without_skill/outputs/。
• 改进现有技能：使用旧版本。编辑前，先为技能创建快照（cp -r <skill-path> <workspace>/skill-snapshot/），然后让基线子 Agent 使用该快照。保存到 old_skill/outputs/。

为每个测试用例编写一个 eval_metadata.json（目前可以不包含断言）。为每个评估指定一个能描述其测试内容的名称，不要只写“eval-0”。目录也使用这个名称。如果本次迭代使用了新的或修改过的评估提示词，请为每个新评估目录创建这些文件——不要假定它们会从之前的迭代沿用。

{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "The user's task prompt",
  "assertions": []
}

第 2 步：运行进行中时，起草断言

不要只是等待运行完成——你可以利用这段时间做些有用的工作。为每个测试用例起草定量断言，并向用户说明这些断言。如果 evals/evals.json 中已有断言，请查看并说明它们检查的内容。

好的断言应当客观可验证，并且名称描述清晰——在基准测试查看器中，它们应一目了然，让浏览结果的人立即明白每条断言检查的内容。对于主观技能（写作风格、设计质量），定性评估效果更好——不要强行对需要人工判断的内容设置断言。

起草完成后，将断言更新到 eval_metadata.json 文件和 evals/evals.json 中。同时向用户说明他们会在查看器中看到什么，包括定性输出和定量基准测试。

第 3 步：运行完成后，记录计时数据

每当某个子 Agent 任务完成，你都会收到包含 total_tokens 和 duration_ms 的通知。立即将这些数据保存到运行目录中的 timing.json：

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

这是记录这些数据的唯一机会——数据通过任务通知传来，不会保存在其他位置。通知到达时应逐条处理，不要等着批量处理。

第 4 步：评分、汇总并启动查看器

所有运行完成后：

1. 为每次运行评分——启动评分器子 Agent（或直接评分），读取 agents/grader.md，并根据输出评估每条断言。将结果保存到每个运行目录中的 grading.json。grading.json 的 expectations 数组必须使用 text、passed 和 evidence 字段（不要使用 name/met/details 或其他字段名变体）——查看器依赖这些确切的字段名。对于可以通过程序检查的断言，请编写并运行脚本，而不是凭目测判断——脚本速度更快、更可靠，也可以在后续迭代中复用。

2. 汇总生成基准测试——运行 skill-creator 目录中的汇总脚本：

   python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
   

   该脚本会生成 benchmark.json 和 benchmark.md，其中包含每种配置的 pass_rate、时间和令牌数，以及均值 ± 标准差和差值。如果手动生成 benchmark.json，请参阅 references/schemas.md，了解查看器所需的确切架构。 请将每个 with_skill 版本放在对应的基线版本之前。

3. 进行分析——阅读基准测试数据，并指出汇总统计数据可能掩盖的规律。关于需要关注的内容（例如无论 skill 如何都始终通过的断言、可能不稳定的高方差评估，以及时间与令牌数之间的权衡），请参阅 agents/analyzer.md 中的“Analyzing Benchmark Results”部分。

4. 启动查看器，同时展示定性输出和定量数据：

   nohup python <skill-creator-path>/eval-viewer/generate_review.py \
     <workspace>/iteration-N \
     --skill-name "my-skill" \
     --benchmark <workspace>/iteration-N/benchmark.json \
     > /dev/null 2>&1 &
   VIEWER_PID=$!
   

   从第 2 次迭代开始，还要传入 --previous-workspace <workspace>/iteration-<N-1>。

   无头环境： 如果 webbrowser.open() 不可用，或环境没有显示设备，请使用 --static <output_path> 写入独立的 HTML 文件，而不是启动服务器。用户点击“Submit All Reviews”后，反馈会以 feedback.json 文件形式下载。下载后，将 feedback.json 复制到 workspace 目录，供下一次迭代读取。

注意：请使用 generate_review.py 创建查看器，无需编写自定义 HTML。

5. 告知用户，例如：“我已在浏览器中打开结果。查看器有两个标签页——‘Outputs’ 可让你浏览每个测试用例并留下反馈；‘Benchmark’ 展示定量对比。完成后，请回到这里告诉我。”

用户在查看器中看到的内容

“Outputs”选项卡一次显示一个测试用例：

• Prompt：给出的任务
• Output：技能生成的文件，并在可能的情况下以内嵌形式呈现
• Previous Output（第 2 次迭代及之后）：折叠区域，显示上一次迭代的输出
• Formal Grades（如果运行了评分）：折叠区域，显示断言通过／失败情况
• Feedback：输入框，输入时会自动保存
• Previous Feedback（第 2 次迭代及之后）：显示在输入框下方的用户上次评论

“Benchmark”选项卡显示统计摘要：每种配置的通过率、耗时和令牌用量，以及各项评估的详细结果和分析员观察。

可通过“上一个”／“下一个”按钮或方向键导航。完成后，点击“Submit All Reviews”，将所有反馈保存到 feedback.json。

步骤 5：阅读反馈

用户告知你已完成后，读取 feedback.json：

{
  "reviews": [
    {"run_id": "eval-0-with_skill", "feedback": "the chart is missing axis labels", "timestamp": "..."},
    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
    {"run_id": "eval-2-with_skill", "feedback": "perfect, love this", "timestamp": "..."}
  ],
  "status": "complete"
}

反馈为空表示用户认为结果不错。重点改进用户明确提出问题的测试用例。

完成后，关闭查看器服务：

kill $VIEWER_PID 2>/dev/null

---

改进技能

这是整个循环的核心。你已运行测试用例，用户也已审核结果，现在需要根据他们的反馈改进技能。

如何思考改进方向

1. 从反馈中归纳出通用规律。 这里的大方向是，我们要打造能被使用百万次（或许真的是百万次，甚至更多，谁知道呢）的技能，来应对各种不同的提示词。在这里，你和用户反复迭代的只是少数几个示例，因为这样能加快进度。用户对这些示例了如指掌，也能快速评估新输出。但如果你和用户共同开发的技能只适用于这些示例，那它就毫无用处。不要添加琐碎、过度拟合的改动，也不要提出过于严苛的 MUST 要求；如果某个问题一直难以解决，可以尝试换用不同的比喻，或推荐不同的工作模式。尝试的成本相对较低，说不定就能找到很好的方案。

2. 保持提示词精简。 删除无关紧要的内容。务必阅读完整记录，而不只是最终输出——如果技能让模型浪费大量时间做无用功，可以尝试删除导致这种行为的部分，看看效果如何。

3. 解释原因。 尽量解释要求模型执行各项操作的原因。如今的大模型很聪明，具备良好的心智理论；只要有合适的框架，就能超越机械地遵循指令，真正把事情做好。即使用户的反馈很简短或带有情绪，也要尽力理解任务本身，以及用户写下这些内容的原因、具体写了什么，再将这些理解融入指令中。如果你发现自己把 ALWAYS 或 NEVER 全部大写，或使用非常僵化的结构，这就是一个警示信号——如果可能，应换一种说法，解释背后的理由，让模型理解你提出该要求的重要性。这种做法更人性化、更有力，也更有效。

4. 留意不同测试用例中的重复劳动。 阅读测试运行记录，观察各个子 Agent 是否都独立编写了类似的辅助脚本，或采用了相同的多步骤方法。如果 3 个测试用例都让子 Agent 编写了 create_docx.py 或 build_chart.py，这强烈表明技能应当将该脚本打包进去。将其编写一次，放入 scripts/，并告知技能使用它。这样今后的每次调用都不必从头再来。

先起草修订版，再以全新视角重新阅读并改进。每项改动都应以用户的实际需求为依据。

迭代循环

改进技能后：

1. 将改进应用到技能
2. 在新的 iteration-<N+1>/ 目录中重新运行所有测试用例，包括基线运行。如果你要创建新技能，基线始终为 without_skill（不使用技能）——在各次迭代中保持不变。如果你要改进现有技能，请自行判断什么适合作为基线：用户最初提供的版本，还是上一轮迭代的版本。
3. 启动审核器，并使用 --previous-workspace 指向上一轮迭代
4. 等待用户审核并告知你审核完毕
5. 阅读新反馈，再次改进并重复

持续迭代，直到：

• 用户表示满意
• 反馈全部为空（看起来一切正常）
• 你已无法取得实质性进展

---

高级：盲测比较

如果你想更严谨地比较某个技能的两个版本（例如，用户询问“新版本真的更好吗？”），可以使用盲测比较系统。阅读 agents/comparator.md 和 agents/analyzer.md 了解详情。基本思路是：将两个输出交给独立 Agent，但不告知哪个对应哪个，让它判断质量。然后分析胜出版本的优势所在。

此功能为可选项，需要子 Agent，大多数用户用不到。通常人工审核循环就足够了。

---

优化描述

SKILL.md frontmatter 中的描述字段，是决定 Agent 是否调用某项技能的主要机制。创建或改进技能后，可主动提出优化描述，以提高触发准确率。

第 1 步：生成触发评测查询

生成 20 条评测查询，包含应触发和不应触发的情况，并保存为 JSON：

[
  {"query": "the user prompt", "should_trigger": true},
  {"query": "another prompt", "should_trigger": false}
]

这些查询必须真实，符合真实 Agent 用户的输入习惯。不要使用抽象请求，而要使用具体、详细的请求。例如，提供文件路径、用户的工作或处境背景信息、列名和值、公司名称、URL 等。可以附带少量背景信息。有些查询可以使用小写、缩写、拼写错误或口语表达。查询长度应有所变化，并重点关注边界情况，而不是明显的例子（用户之后有机会确认这些查询）。

不佳："格式化这些数据"、"从 PDF 中提取文本"、"创建图表"

较佳："好吧，我老板刚发给我这个 xlsx 文件（在下载文件夹里，文件名好像是 'Q4 sales final FINAL v2.xlsx'），她想让我加一列，用百分比显示利润率。收入在 C 列，成本在 D 列，我想应该是这样"

对于应触发的查询（8-10 条），要考虑覆盖范围。要用不同说法表达相同意图——有些正式，有些随意。也要包含用户没有明确提到技能名称或文件类型，但显然需要该技能的情况。加入一些少见用例，以及与其他技能存在竞争但应由此技能处理的情况。

对于不应触发的查询（8-10 条），最有价值的是容易混淆的情况——这些查询与该技能共享关键词或概念，但实际需要的是其他处理。考虑相邻领域、容易让简单关键词匹配误触发的模糊表达，以及虽然涉及该技能的能力，但在特定场景下更适合使用其他工具的情况。

关键是避免：不要让不应触发的查询明显无关。例如，用“编写一个斐波那契函数”作为 PDF 技能的负向测试过于简单，无法检验任何问题。负向案例应当足够棘手。

步骤 2：与用户一起审核

使用 HTML 模板向用户展示评估集，以供审核：

1. 从 assets/eval_review.html 读取模板
2. 替换占位符：
   • __EVAL_DATA_PLACEHOLDER__ → 评估项的 JSON 数组（不要加引号——这是一个 JS 变量赋值）
   • __SKILL_NAME_PLACEHOLDER__ → 技能名称
   • __SKILL_DESCRIPTION_PLACEHOLDER__ → 技能当前的描述
3. 写入临时文件（例如 /tmp/eval_review_<skill-name>.html）并打开：python -m webbrowser /tmp/eval_review_<skill-name>.html
4. 用户可以编辑查询、切换 should-trigger、添加／移除条目，然后点击 "Export Eval Set"
5. 文件会下载到 ~/Downloads/eval_set.json——如果有多个版本（例如 eval_set (1).json），请检查 Downloads 文件夹并选择最新版本

这一步很重要——糟糕的评估查询会导致糟糕的描述。

步骤 3：运行优化循环

告诉用户：“这需要一些时间——我会在后台运行优化循环，并定期查看进度。”

将评估集保存到工作区，然后在后台运行：

python -m scripts.run_loop \
  --eval-set <path-to-trigger-eval.json> \
  --skill-path <path-to-skill> \
  --platform <claude-code|openclaw|codex> \
  --optimizer-platform <auto|claude-code|openclaw|codex|anthropic> \
  --model <optional-model-id-for-the-selected-runtime> \
  --max-iterations 5 \
  --verbose

默认情况下，优化器运行时应与评估平台一致。只有当你有意使用一个主机进行评估、同时使用另一个主机重写描述时，才覆盖 --optimizer-platform。在 OpenClaw 上测试时，请传入 --platform openclaw（以及可选的 --openclaw-agent <id>）。

运行期间，定期查看输出，为用户更新当前迭代次数和得分情况。

此流程会自动处理完整的优化循环。它会将评估集拆分为 60% 的训练集和 40% 的留出测试集，评估当前描述（每个查询运行 3 次，以获得可靠的触发率），然后调用所选的优化器运行时，根据失败情况提出改进方案。它会在训练集和测试集上重新评估每个新描述，最多迭代 5 次。完成后，它会在浏览器中打开 HTML 报告，显示每轮迭代的结果，并返回包含 best_description 的 JSON——该描述根据测试集得分而非训练集得分选出，以避免过拟合。

技能触发机制

了解触发机制有助于设计更好的评估查询。技能会以名称和描述显示在 Agent 的可用技能列表中，Agent 会根据描述决定是否查阅某项技能。重要的是，Agent 只会在无法轻松自行处理任务时查阅技能——即使描述完全匹配，简单的单步骤查询也可能不会触发技能。描述匹配时，复杂、多步骤或专业化的查询通常能可靠地触发技能。

不同主机的检测质量有所不同：

• Claude Code：优化器可以检查真实的 Skill/Read 工具事件，因此触发评估结果具有权威性。
• Codex CLI / OpenClaw：当前公开的 CLI 不会以此工具可使用的方式提供权威的技能加载事件，因此触发评估使用有文档说明的启发式代理方法（临时技能会要求模型在被激活时输出一个哨兵短语）。这些得分有参考价值，但并非绝对准确。

因此，评估查询应当足够实质，让 Agent 确实能从查阅技能中受益。像“读取文件 X”这样的简单查询不是好的测试用例——无论描述质量如何，它们都不会触发技能。

步骤 4：应用结果

从 JSON 输出中获取 best_description，并更新技能的 SKILL.md frontmatter。向用户展示修改前后的内容，并报告得分。

---

打包并展示

如果目标生态系统要求提供可安装的包，请打包技能，并将生成的 .skill 文件路径告知用户。否则，直接分享文件夹即可。

python -m scripts.package_skill <path/to/skill-folder>

打包后，告知用户生成的 .skill 文件路径，以便他们安装。

参考文件

agents/ 目录包含专用子 Agent 的说明。需要启用相关子 Agent 时，请阅读这些说明。

• agents/grader.md — 如何根据输出评估断言
• agents/comparator.md — 如何对两个输出进行盲测 A/B 比较
• agents/analyzer.md — 如何分析某个版本胜出的原因

references/ 目录包含其他文档：

• references/schemas.md — evals.json、grading.json 等文件的 JSON 结构

---

为强调重点，这里再重复一次核心循环：

• 弄清楚技能的用途
• 起草或编辑技能
• 在测试提示词上运行 claude-with-access-to-the-skill
• 与用户一起评估输出：
  • 创建 benchmark.json，并运行 eval-viewer/generate_review.py，帮助用户审核输出
  • 运行定量评估
• 重复以上步骤，直到你和用户都满意
• 打包最终技能并交付给用户。

如果你有 TodoList，请添加相应步骤，确保不会遗漏。尤其要确保在 TodoList 中添加“创建 evals JSON 并运行 eval-viewer/generate_review.py，以便人工审核测试用例”，避免跳过这一步。

祝你好运！