技能创建器

一个用于创建新技能并迭代改进它们的技能。

从宏观层面来看，创建技能的过程如下：

确定你希望技能做什么以及大致的实现方式
撰写技能草稿
创建几个测试提示词，并在"带技能的 Claude"上运行
帮助用户从定性和定量两个方面评估结果
- 在后台运行的同时，如果还没有定量评估，就起草一些（如果已有则直接使用或按需修改）。然后向用户解释它们（或者如果已经存在，解释现有的评估）
- 使用 eval-viewer/generate_review.py 脚本向用户展示结果，同时让他们查看定量指标
根据用户评估的反馈重写技能（如果定量基准测试中有明显缺陷，也一并修复）
反复迭代直到满意
扩大测试集并再次大规模测试

你使用此技能时的任务是弄清楚用户处于这个流程的哪个阶段，然后介入帮助他们推进。例如，用户可能说"我想做一个关于 X 的技能"。你可以帮助缩小范围、撰写草稿、编写测试用例、确定评估方式、运行所有提示词并反复迭代。

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

当然，你应该始终保持灵活——如果用户说"我不需要跑一堆评估，随意聊就好"，你完全可以这样做。

然后在技能完成之后（顺序是灵活的），你还可以运行技能描述优化器——我们有一个专门的脚本来优化技能的触发效果。

与用户沟通

技能创建器的使用者可能来自各种技术背景。如果你还不知道的话（这确实是最近才开始的趋势），Claude 的强大能力正在激励水管工打开终端、父母和祖父母去搜索"如何安装 npm"。另一方面，大部分用户可能是相当有计算机素养的。

所以请注意上下文线索来理解如何措辞！在默认情况下，给你一些参考：

"评估"和"基准测试"这类术语是可以使用的
对于"JSON"和"断言"这类术语，你需要看到用户明确的信号表明他们了解这些概念后再使用，否则需要简单解释

如果你不确定，简要解释术语是完全没问题的，如果不确定用户是否理解，可以附上简短的定义。

创建技能

捕获意图

首先理解用户的意图。当前对话可能已经包含了用户想要捕获的工作流（例如，他们说"把这个变成技能"）。如果是这样，先从对话历史中提取答案——使用的工具、步骤顺序、用户做的修正、观察到的输入/输出格式。用户可能需要填补一些空白，并在进入下一步之前确认。

这个技能应该让 Claude 能做什么？
什么时候应该触发这个技能？（什么用户短语/上下文）
预期的输出格式是什么？
是否需要设置测试用例来验证技能？对于输出可以客观验证的技能（文件转换、数据提取、代码生成、固定工作流步骤）适合使用测试用例。输出主观性较强的技能（写作风格、艺术）通常不需要。根据技能类型建议合适的默认选项，但让用户决定。

访谈与调研

主动询问边界情况、输入/输出格式、示例文件、成功标准和依赖项。在这些问题搞清楚之前，暂缓编写测试提示词。

检查可用的 MCP——如果 MCP 对调研有用（搜索文档、查找类似技能、查阅最佳实践），尽可能通过子代理并行调研（如果可用），否则内联处理。准备好上下文以减少用户的负担。

编写 SKILL.md

根据用户访谈，填写以下组件：

name：技能标识符
description：何时触发、做什么。这是主要的触发机制——包含技能做什么以及使用场景。所有"何时使用"的信息都放在这里，而不是正文中。注意：目前 Claude 有"触发不足"的倾向——在技能有用时不使用它们。为了解决这个问题，请让技能描述稍微"主动"一些。例如，与其写"如何构建一个简单快速的仪表板来显示内部 Anthropic 数据"，不如写"如何构建一个简单快速的仪表板来显示内部 Anthropic 数据。确保在用户提到仪表板、数据可视化、内部指标或想要显示任何类型的数据时都使用此技能，即使他们没有明确要求'仪表板'。"
compatibility：所需工具、依赖项（可选，很少需要）
技能正文 :)

技能编写指南

技能的结构

skill-name/
├── SKILL.md（必需）
│   ├── YAML 前置元数据（name、description 必填）
│   └── Markdown 指令
└── 捆绑资源（可选）
    ├── scripts/    - 用于确定性/重复性任务的可执行代码
    ├── references/ - 按需加载到上下文中的文档
    └── assets/     - 输出中使用的文件（模板、图标、字体）

渐进式披露

技能使用三级加载系统：

元数据（name + description）- 始终在上下文中（约100词）
SKILL.md 正文 - 技能触发时加载（理想情况下不超过500行）
捆绑资源 - 按需加载（无限制，脚本无需加载即可执行）

这些字数是近似值，如果需要可以更长。

关键模式：

保持 SKILL.md 在500行以内；如果接近这个限制，添加额外的层次结构和清晰的指引，说明模型接下来应该去哪里查看后续内容。
从 SKILL.md 中清晰地引用文件，并说明何时需要阅读它们
对于大型参考文件（超过300行），包含目录

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

cloud-deploy/
├── SKILL.md（工作流 + 选择逻辑）
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

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

无意外原则

不言而喻，技能不得包含恶意软件、漏洞利用代码或任何可能危害系统安全的内容。技能的内容在被描述时不应让用户感到意外。不要配合创建误导性技能或设计用于促进未授权访问、数据窃取或其他恶意活动的技能。不过像"扮演 XYZ 角色"这类请求是可以的。

编写模式

在指令中优先使用祈使句。

定义输出格式 - 你可以这样做：

## 报告结构
始终使用以下模板：
# [标题]
## 执行摘要
## 关键发现
## 建议

示例模式 - 包含示例是有用的。你可以这样格式化它们（但如果示例中已有"输入"和"输出"，你可能需要稍微调整）：

## 提交消息格式
**示例 1：**
输入：添加了使用 JWT 令牌的用户认证
输出：feat(auth): implement JWT-based authentication

编写风格

尽量向模型解释事物为何重要，而不是使用繁重的强制 MUST。运用心智理论，让技能通用而不是狭隘地针对特定示例。先写草稿，然后用新的视角审视并改进它。

测试用例

编写技能草稿后，想出2-3个真实的测试提示词——那种真实用户实际会说的话。与用户分享："这里有几个我想试试的测试用例。这些看起来对吗，还是你想添加更多？"然后运行它们。

将测试用例保存到 evals/evals.json。暂时不要写断言——只写提示词。你将在下一步中利用运行等待时间起草断言。

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "用户的任务提示词",
      "expected_output": "预期结果描述",
      "files": []
    }
  ]
}

完整 schema（包括 assertions 字段，你会在后面添加）请参见 references/schemas.md。

运行和评估测试用例

本节是一个连续序列——不要中途停下。不要使用 /skill-test 或任何其他测试技能。

将结果放在 <skill-name>-workspace/ 中，作为技能目录的兄弟目录。在工作空间内，按迭代组织结果（iteration-1/、iteration-2/ 等），每个迭代中每个测试用例有一个目录（eval-0/、eval-1/ 等）。不要预先创建所有目录——在需要时创建。

第1步：在同一轮中同时触发所有运行（带技能和基线）

对于每个测试用例，在同一轮中启动两个子代理——一个带技能，一个不带。这很重要：不要先启动带技能的运行然后再回来跑基线。同时启动所有运行，这样它们大约在同一时间完成。

带技能运行：

执行此任务：
- 技能路径：<path-to-skill>
- 任务：<eval prompt>
- 输入文件：<eval files if any, or "none">
- 将输出保存到：<workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- 需保存的输出：<用户关心的内容——例如 "the .docx file", "the final CSV">

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

创建新技能：完全不用技能。相同提示词，无技能路径，保存到 without_skill/outputs/。
改进现有技能：使用旧版本。编辑前先快照技能（cp -r <skill-path> <workspace>/skill-snapshot/），然后将基线子代理指向快照。保存到 old_skill/outputs/。

为每个测试用例编写 eval_metadata.json（断言暂时可以为空）。给每个评估起一个描述性名称，基于它测试的内容——不要只叫"eval-0"。将此名称也用于目录名。如果这次迭代使用了新的或修改的评估提示词，为每个新的评估目录创建这些文件——不要假设它们从上次迭代继承。

{
  "eval_id": 0,
  "eval_name": "描述性名称",
  "prompt": "用户的任务提示词",
  "assertions": []
}

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

不要只是等运行完成——你可以利用这段时间做有意义的工作。为每个测试用例起草定量断言，并向用户解释。如果断言已存在于 evals/evals.json 中，审查它们并解释检查了什么。

好的断言是可客观验证的，并且有描述性名称——它们应该在基准测试查看器中清晰可读，让查看结果的人一目了然地知道每个断言检查了什么。主观性技能（写作风格、设计质量）更适合定性评估——不要对需要人类判断的东西强加断言。

用起草好的断言更新 eval_metadata.json 文件和 evals/evals.json。同时向用户解释他们将在查看器中看到什么——包括定性输出和定量基准测试。

第3步：运行完成后捕获计时数据

当每个子代理任务完成时，你会收到一个包含 total_tokens 和 duration_ms 的通知。立即将此数据保存到运行目录中的 timing.json：

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

这是捕获此数据的唯一机会——它通过任务通知传递，不会在其他地方持久化。逐个处理通知，而不是批量处理。

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

所有运行完成后：

评分每次运行 — 启动评分子代理（或内联评分），读取 agents/grader.md，根据每个断言评估输出。将结果保存到每个运行目录中的 grading.json。grading.json 的 expectations 数组必须使用字段 text、passed 和 evidence（不是 name/met/details 或其他变体）——查看器依赖这些确切的字段名。对于可以通过编程检查的断言，编写并运行脚本而不是用肉眼看——脚本更快、更可靠且可跨迭代复用。
汇总成基准测试 — 从 skill-creator 目录运行汇总脚本：
```
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
```
这会生成 benchmark.json 和 benchmark.md，包含每种配置的通过率、时间和 token 用量，带均值 ± 标准差和差异。如果手动生成 benchmark.json，请参阅 references/schemas.md 获取查看器期望的确切 schema。将每个 with_skill 版本放在其基线对应项之前。
分析 — 阅读基准测试数据并发现汇总统计可能隐藏的模式。参见 agents/analyzer.md（"分析基准测试结果"部分）了解需要关注的内容——例如无论是否使用技能都总是通过的断言（无区分度）、高方差评估（可能不稳定）以及时间/token 权衡。
启动查看器，同时展示定性输出和定量数据：
```
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 文件而不是启动服务器。用户点击"提交所有评审"时反馈会下载为 feedback.json 文件。下载后，将 feedback.json 复制到工作空间目录中供下次迭代使用。

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

告知用户，类似这样："我已在浏览器中打开了结果。有两个标签页——'输出'让你逐个浏览测试用例并留下反馈，'基准测试'显示定量比较。完成后回来告诉我。"

用户在查看器中看到什么

"输出"标签页每次显示一个测试用例：

提示词：给出的任务
输出：技能生成的文件，尽可能内联渲染
上一次输出（第2次迭代起）：折叠部分，显示上次迭代的输出
正式评分（如果进行了评分）：折叠部分，显示断言通过/失败
反馈：一个自动保存的文本框
上一次反馈（第2次迭代起）：他们上次的评论，显示在文本框下方

"基准测试"标签页显示统计摘要：每种配置的通过率、时间和 token 用量，带逐项细分和分析观察。

导航通过上一个/下一个按钮或方向键。完成后点击"提交所有评审"，将所有反馈保存到 feedback.json。

第5步：读取反馈

当用户告诉你他们完成了，读取 feedback.json：

{
  "reviews": [
    {"run_id": "eval-0-with_skill", "feedback": "图表缺少坐标轴标签", "timestamp": "..."},
    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
    {"run_id": "eval-2-with_skill", "feedback": "完美，很喜欢", "timestamp": "..."}
  ],
  "status": "complete"
}

空反馈意味着用户认为结果没问题。将改进重点放在用户有具体意见的测试用例上。

完成后终止查看器服务：

kill $VIEWER_PID 2>/dev/null

改进技能

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

如何思考改进

从反馈中泛化。 这里真正发生的大事是——我们试图创建可以被使用百万次（也许真的百万次，甚至更多，谁知道呢）的技能，跨越众多不同的提示词。这里你和用户只在几个示例上反复迭代，因为这样更快。用户对这些示例了如指掌，他们可以快速评估新输出。但如果你和用户共同开发的技能只对这些示例有效，那它就是无用的。与其做繁琐的过拟合修改或过度限制性的 MUST，如果有某个顽固的问题，你可以试试换个方向，使用不同的隐喻或推荐不同的工作模式。尝试成本相对较低，也许你会发现很棒的方案。
保持提示词精简。 移除那些没有发挥作用的内容。确保阅读记录（transcript），而不只是最终输出——如果看起来技能让模型浪费大量时间在无效操作上，你可以尝试去掉技能中导致这些操作的部分，看看会发生什么。
解释原因。 尽力解释你要求模型做的每件事的原因。当今的大语言模型很聪明。它们有良好的心智理论，在给予好的框架后可以超越机械指令，真正把事情做好。即使用户的反馈简短或带有挫败感，也要尝试真正理解任务、理解用户为什么写了这些内容、他们实际写了什么，然后将这种理解传递到指令中。如果你发现自己在写全大写的"始终"或"绝不"，或使用超级僵化的结构，这是一个黄色信号——如果可能的话，重新组织并解释推理过程，让模型理解你要求的事情为什么重要。这是一种更人性化、更强大、更有效的方法。
寻找测试用例之间的重复工作。 阅读测试运行的记录，注意子代理是否都独立编写了类似的辅助脚本或采取了相同的多步骤方法。如果所有3个测试用例都导致子代理编写了 create_docx.py 或 build_chart.py，这是一个强烈信号，表明技能应该捆绑该脚本。编写一次，放入 scripts/，并告诉技能使用它。这样可以让未来的每次调用都不必重新发明轮子。

这个任务非常重要（我们正试图创造每年数十亿的经济价值！），你的思考时间不是瓶颈；花时间仔细琢磨。建议先写一个修订草稿，然后用全新的视角审视并改进。真正努力站在用户的角度思考，理解他们想要和需要什么。

迭代循环

改进技能后：

将改进应用到技能
在新的 iteration-<N+1>/ 目录中重新运行所有测试用例，包括基线运行。如果你在创建新技能，基线始终是 without_skill（无技能）——这在迭代中保持不变。如果你在改进现有技能，根据判断决定什么作为基线更合理：用户最初带来的原始版本，还是前一次迭代。
启动审查器，--previous-workspace 指向上一次迭代
等待用户审查并告诉你完成了
阅读新反馈，再次改进，重复

持续进行直到：

用户表示满意
反馈全部为空（一切看起来都好）
你没有在做有意义的进展

进阶：盲审比较

在需要更严格地比较两个技能版本的情况下（例如，用户问"新版本真的更好吗？"），有一个盲审比较系统。阅读 agents/comparator.md 和 agents/analyzer.md 了解详情。基本思路是：将两个输出交给一个独立代理，不告诉它哪个是哪个，让它评判质量。然后分析获胜者为何获胜。

这是可选的，需要子代理，大多数用户不需要它。人类审查循环通常就足够了。

描述优化

SKILL.md 前置元数据中的 description 字段是决定 Claude 是否调用技能的主要机制。在创建或改进技能后，提议优化描述以提升触发准确性。

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

创建20个评估查询——混合"应该触发"和"不应该触发"的。保存为 JSON：

[
  {"query": "用户提示词", "should_trigger": true},
  {"query": "另一个提示词", "should_trigger": false}
]

查询必须是真实的，并且是 Claude Code 或 Claude.ai 用户实际会输入的内容。不是抽象请求，而是具体、详细的请求。例如，文件路径、用户工作或情况的个人背景、列名和值、公司名称、URL。一些背景故事。有些可能是小写的或包含缩写、拼写错误或随意措辞。使用不同长度的混合，重点关注边缘情况而不是一目了然的情况（用户会有机会审核它们）。

不好的例子："格式化这个数据"、"从 PDF 中提取文本"、"创建一个图表"

好的例子："我老板刚给我发了一个 xlsx 文件（在我的下载文件夹里，好像叫'第四季度销售最终版最终版 v2.xlsx'之类的），她想让我加一列显示利润率百分比。收入在 C 列，成本我觉得在 D 列"

对于应该触发的查询（8-10个），考虑覆盖面。你需要同一意图的不同表述——有些正式，有些随意。包含用户没有明确提到技能或文件类型但显然需要它的情况。加入一些不常见的用例以及技能与其他技能竞争但应该胜出的情况。

对于不应该触发的查询（8-10个），最有价值的是近似匹配——与技能共享关键词或概念但实际需要不同东西的查询。想想相邻领域、天真的关键词匹配会触发但不应该触发的模糊措辞，以及查询涉及技能功能但在另一个工具更合适的上下文中的情况。

需要避免的关键点：不要让"不应该触发"的查询明显不相关。"写一个斐波那契函数"作为 PDF 技能的负面测试太简单了——它什么都测不出来。负面用例应该是真正有难度的。

第2步：与用户审核

使用 HTML 模板向用户展示评估集进行审核：

读取 assets/eval_review.html 模板
替换占位符：
- __EVAL_DATA_PLACEHOLDER__ → 评估项的 JSON 数组（不要加引号——它是一个 JS 变量赋值）
- __SKILL_NAME_PLACEHOLDER__ → 技能名称
- __SKILL_DESCRIPTION_PLACEHOLDER__ → 技能当前描述
写入临时文件（例如 /tmp/eval_review_<skill-name>.html）并打开它：open /tmp/eval_review_<skill-name>.html
用户可以编辑查询、切换是否应触发、添加/删除条目，然后点击"导出评估集"
文件下载到 ~/Downloads/eval_set.json——检查下载文件夹中最新版本，以防有多个（例如 eval_set (1).json）

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

第3步：运行优化循环

告诉用户："这需要一些时间——我会在后台运行优化循环并定期检查。"

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

python -m scripts.run_loop \
  --eval-set <path-to-trigger-eval.json> \
  --skill-path <path-to-skill> \
  --model <model-id-powering-this-session> \
  --max-iterations 5 \
  --verbose

使用你的系统提示词中的模型 ID（驱动当前会话的那个），这样触发测试与用户实际体验匹配。

运行期间，定期查看输出，向用户更新当前在哪次迭代以及分数情况。

这会自动处理完整的优化循环。它将评估集分为60%训练集和40%保留测试集，评估当前描述（每个查询运行3次以获得可靠的触发率），然后调用带扩展思考的 Claude 提出基于失败案例的改进建议。它在训练集和测试集上重新评估每个新描述，迭代最多5次。完成后，它在浏览器中打开一个 HTML 报告，显示每次迭代的结果，并返回包含 best_description 的 JSON——通过测试分数而非训练分数来选择，以避免过拟合。

技能触发工作原理

理解触发机制有助于设计更好的评估查询。技能以 name + description 出现在 Claude 的 available_skills 列表中，Claude 根据该描述决定是否使用技能。需要知道的重要一点是 Claude 只在无法轻松独立处理的任务上使用技能——像"读取这个 PDF"这样的简单单步查询可能不会触发技能，即使描述完美匹配，因为 Claude 可以直接用基本工具处理。复杂的、多步骤的或专业的查询在描述匹配时可靠地触发技能。

这意味着你的评估查询应该足够实质性，使 Claude 确实能从使用技能中受益。简单查询如"读取文件 X"是糟糕的测试用例——它们无论描述质量如何都不会触发技能。

第4步：应用结果

从 JSON 输出中取 best_description 并更新技能的 SKILL.md 前置元数据。向用户展示前后对比并报告分数。

打包和展示（仅当 `present_files` 工具可用时）

检查你是否有 present_files 工具的访问权限。如果没有，跳过此步骤。如果有，打包技能并向用户展示 .skill 文件：

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

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

Claude.ai 特定说明

在 Claude.ai 中，核心工作流相同（草稿 → 测试 → 审查 → 改进 → 重复），但由于 Claude.ai 没有子代理，一些机制需要变化。以下是需要调整的内容：

运行测试用例：没有子代理意味着无法并行执行。对于每个测试用例，阅读技能的 SKILL.md，然后按照它的指令自己完成测试提示词。逐个执行。这不如独立子代理严格（你编写了技能也在运行它，所以你有完整上下文），但这是一个有用的合理性检查——人类审查步骤可以弥补。跳过基线运行——只使用技能完成请求的任务。

审查结果：如果你无法打开浏览器（例如 Claude.ai 的虚拟机没有显示器，或你在远程服务器上），完全跳过浏览器审查器。直接在对话中展示结果。对于每个测试用例，显示提示词和输出。如果输出是用户需要查看的文件（如 .docx 或 .xlsx），保存到文件系统并告诉他们位置以便下载和检查。内联请求反馈："这个看起来怎么样？有什么要改的吗？"

基准测试：跳过定量基准测试——它依赖于在没有子代理的情况下无意义的基线比较。专注于用户的定性反馈。

迭代循环：与之前相同——改进技能、重新运行测试用例、请求反馈——只是中间没有浏览器审查器。如果有文件系统，你仍然可以将结果组织到迭代目录中。

描述优化：此部分需要 claude CLI 工具（特别是 claude -p），仅在 Claude Code 中可用。如果在 Claude.ai 上则跳过。

盲审比较：需要子代理。跳过。

打包：package_skill.py 脚本在任何有 Python 和文件系统的地方都能工作。在 Claude.ai 上，你可以运行它，用户可以下载生成的 .skill 文件。

协作环境特定说明

如果你在协作环境（Cowork）中，主要需要知道的是：

你有子代理可用，所以主工作流（并行启动测试用例、运行基线、评分等）都能工作。（但是，如果遇到严重的超时问题，可以串行运行测试提示词而非并行。）
你没有浏览器或显示器，所以生成评估查看器时，使用 --static <output_path> 来写入一个独立的 HTML 文件而不是启动服务器。然后提供一个链接让用户点击在浏览器中打开 HTML。
无论什么原因，协作环境似乎让 Claude 不太愿意在运行测试后生成评估查看器，所以再强调一次：无论你在协作环境还是 Claude Code 中，运行测试后，你都应该始终使用 generate_review.py 为人类生成评估查看器来查看示例（不是编写你自己的定制 HTML 代码），然后再自己评估输入并尝试修正。抱歉我要用大写了：在自己评估输入之前生成评估查看器。你要尽快把结果放到人类面前！
反馈的工作方式不同：由于没有运行中的服务器，查看器的"提交所有评审"按钮会下载 feedback.json 文件。然后你可以从那里读取它（可能需要先请求访问权限）。
打包可以工作——package_skill.py 只需要 Python 和文件系统。
描述优化（run_loop.py / run_eval.py）在协作环境中应该能正常工作，因为它使用 claude -p 的子进程而非浏览器，但请在完全完成技能制作且用户同意技能状态良好后再进行。

参考文件

agents/ 目录包含专用子代理的指导说明。当你需要启动相关子代理时读取它们。

agents/grader.md — 如何根据输出评估断言
agents/comparator.md — 如何在两个输出之间进行盲审 A/B 比较
agents/analyzer.md — 如何分析为什么一个版本胜出

references/ 目录有额外文档：

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

再次强调核心循环：

弄清楚技能是关于什么的
起草或编辑技能
在测试提示词上运行"带技能的 Claude"
与用户一起评估输出：
- 创建 benchmark.json 并运行 eval-viewer/generate_review.py 帮助用户审查
- 运行定量评估
重复直到你和用户都满意
打包最终技能并返回给用户。

请将步骤添加到你的待办列表中（如果你有这样的功能），以确保你不会遗忘。如果你在协作环境中，请特别将"创建评估 JSON 并运行 eval-viewer/generate_review.py 以便人类审查测试用例"放入待办列表，确保它执行。

祝你好运！