技能创建器

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

在高层次上，创建技能的过程大致如下：

• 确定你希望该技能实现什么功能，以及大致如何实现
• 撰写技能的初稿
• 创建几个测试提示（prompts），并在这些提示上运行具备该技能访问权限的 Claude
• 帮助用户对结果进行定性和定量评估
  在后台运行测试的同时，如果没有现成的定量评估方案，则起草一些（如果已有，则可直接使用，或根据需要进行修改）。然后向用户解释这些评估方案（如果已有，则解释现有的方案）
  使用 eval-viewer/generate_review.py 脚本向用户展示结果供其查看，同时允许他们查看定量指标
• 根据用户对结果的评估反馈（以及从定量基准测试中发现的明显缺陷）重写技能
• 重复上述过程，直到满意为止
• 扩展测试集，并在更大规模上再次尝试

当你使用此技能时，你的任务是判断用户当前处于该流程的哪个阶段，然后介入并帮助他们推进到下一阶段。例如，用户可能会说：“我想为 X 创建一个技能。” 你可以帮助他们明确具体需求、撰写初稿、编写测试用例、确定评估方式、运行所有提示，并不断迭代。

另一方面，如果用户已经拥有技能的草稿，那么你可以直接进入评估/迭代环节。

当然，你也应始终保持灵活性；如果用户表示“我不需要运行大量评估，咱们凭感觉来就行”，那你也可以照做。

此外，在技能完成后（同样，顺序可以灵活调整），你还可以运行技能描述优化器——我们为此专门准备了一个独立脚本——以优化技能的触发效果。

明白了吗？明白了。

与用户沟通

技能创建器可能会被各种熟悉编程术语程度不同的用户使用。如果你还没听说（你怎么可能听说呢，毕竟这趋势才刚刚兴起），现在有一种潮流：Claude 的强大能力正激励水管工们打开终端，促使父母和祖父母去谷歌搜索“如何安装 npm”。另一方面，大多数用户可能具备相当的计算机素养。

因此，请注意上下文线索，以判断该如何措辞！作为默认情况，给你一些参考：

• “评估（evaluation）”和“基准测试（benchmark）”属于临界词汇，但可以接受
• 对于“JSON”和“断言（assertion）”，你需要观察用户是否明确表现出了解这些术语，再决定是否直接使用而不加解释

如果你不确定，简要解释一下术语是可以的；如果你不确定用户是否理解某个术语，不妨附上简短定义予以澄清。

---

创建技能

捕捉意图

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

1. 此技能应使 Claude 能够做什么？
2. 此技能应在何时触发？（哪些用户语句/上下文）
3. 预期的输出格式是什么？
4. 是否需要设置测试用例来验证技能是否正常工作？对于输出可客观验证的技能（如文件转换、数据提取、代码生成、固定工作流步骤）而言，测试用例很有帮助；而对于输出主观性强的技能（如写作风格、艺术创作）则通常不需要。根据技能类型建议合适的默认选项，但最终由用户决定。

访谈与调研

主动询问关于边界情况、输入/输出格式、示例文件、成功标准和依赖项的问题。在这些问题理清之前，不要急于编写测试提示。

检查可用的 MCP —— 如果对调研有帮助（如搜索文档、查找类似技能、查阅最佳实践），在有子代理可用的情况下可并行进行调研，否则就内联完成。准备好相关上下文，以减轻用户负担。

编写 SKILL.md

根据用户访谈结果，填写以下组成部分：

• name: 技能标识符
• description: 触发条件及功能说明。这是主要的触发机制——需同时包含技能的功能说明以及具体的使用场景。所有“何时使用”的信息都应放在这里，而不是放在正文部分。注意：目前 Claude 倾向于“触发不足”——即在应该使用技能时却未使用。为解决此问题，请让技能描述稍微“主动”一些。例如，与其写成“如何构建一个简单的快速仪表板来展示 Anthropic 内部数据”，不如写成“如何构建一个简单的快速仪表板来展示 Anthropic 内部数据。只要用户提到仪表板、数据可视化、内部指标，或希望展示任何类型的公司数据，即使他们没有明确要求‘仪表板’，也务必使用此技能。”
• 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
    └── assets/     - Files used in output (templates, icons, fonts)

渐进式披露

技能采用三级加载系统：

1. 元数据（名称 + 描述）- 始终在上下文中（约 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

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

无意外原则

这一点不言而喻，但技能不得包含恶意软件、利用代码或任何可能危及系统安全的内容。技能的内容在其描述意图上不应让用户感到意外。不要配合创建具有误导性的技能，或旨在促进未授权访问、数据窃取或其他恶意活动的技能。“扮演 XYZ 角色”之类的内容是可以接受的。

编写模式

在指令中优先使用祈使语气。

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

## Report structure
ALWAYS use this exact template:
# [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": []
    }
  ]
}

完整 schema 请参见 references/schemas.md（包括稍后要添加的 assertions 字段）。

运行和评估测试用例

本节为连续操作流程——请勿中途停止。切勿使用 /skill-test 或任何其他测试技能。

将结果放入 <skill-name>-workspace/ 目录中，该目录与技能目录同级。在工作区中，按迭代次数组织结果（iteration-1/、iteration-2/ 等），每个测试用例在对应迭代下拥有自己的目录（eval-0/、eval-1/ 等）。无需提前创建所有目录——边进行边创建即可。

步骤 1：在同一轮次中启动所有运行（带技能版 AND 基线版）

对每个测试用例，在同一轮次中启动两个子代理——一个带技能，一个不带技能。这一点很重要：不要先启动带技能的运行，稍后再回来处理基线版本。一次性启动所有任务，以便它们大致同时完成。

带技能运行：

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/），然后将基线子代理指向该快照。保存到 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：运行完成后，捕获计时数据

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

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

这是捕获该数据的唯一机会——它通过任务通知传递，不会在其他地方持久化。请在每条通知到达时立即处理，而不是尝试批量处理。

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

当所有运行完成后：

1. 对每次运行进行评分——启动一个评分子代理（或内联评分），读取 agents/grader.md 并针对输出评估每个断言。将结果保存到各运行目录中的 grading.json。grading.json 中的 expectations 数组必须使用 text、passed 和 evidence 字段（不能使用 name/met/details 或其他变体）——查看器依赖这些确切的字段名。对于可通过编程方式检查的断言，请编写并运行脚本而非人工目测——脚本更快、更可靠，并可在多次迭代中复用。

1. 汇总成基准报告——从技能创建者目录运行汇总脚本： ```bash python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name> ``` 这将生成 benchmark.json 和 benchmark.md，其中包含每个配置的通过率、时间和 token 数，并附带均值 ± 标准差及变化量（delta）。如果手动生成 benchmark.json，请参阅 references/schemas.md 获取查看器所期望的确切 schema。

将每个 with_skill 版本放在其对应的基线版本之前。

1. 进行分析师复核——阅读基准数据，揭示汇总统计数据可能掩盖的模式。参见 agents/analyzer.md（“分析基准结果”部分）了解应关注的内容——例如无论技能如何都始终通过的断言（无区分度）、高方差的评估（可能不稳定），以及时间/token 的权衡。

1. 启动查看器，同时展示定性输出和量化数据： ```bash 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。

1. 告知用户类似以下内容：“我已在您的浏览器中打开了结果。有两个标签页——‘Outputs’ 允许您逐个查看测试用例并留下反馈，‘Benchmark’ 显示量化对比。完成后，请回到这里告诉我。”

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

“Outputs” 标签页一次显示一个测试用例：

• Prompt：所给的任务
• Output：技能生成的文件，尽可能以内联方式渲染
• Previous Output（第 2 次及以后的迭代）：折叠区域，显示上一次迭代的输出
• Formal Grades（如果运行了评分）：折叠区域，显示断言通过/失败情况
• Feedback：一个文本框，用户输入时自动保存
• Previous Feedback（第 2 次及以后的迭代）：显示用户上次的评论，位于文本框下方

“Benchmark”（基准）标签页显示统计摘要：每个配置的通过率、耗时和 token 使用情况，并附带每次评估的详细分解和分析师观察。

导航可通过上一页/下一页按钮或方向键进行。完成后，用户点击“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"
}

空反馈表示用户认为结果没问题。请将改进重点放在用户有具体抱怨的测试用例上。

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

kill $VIEWER_PID 2>/dev/null

---

改进技能

这是整个循环的核心。你已经运行了测试用例，用户也评审了结果，现在你需要根据他们的反馈让技能变得更好。

如何思考改进

1. 从反馈中归纳总结。 核心目标是创建能够被使用百万次（也许是字面意义上的百万次，甚至更多）的技能，适用于各种不同的提示。你和用户在此反复迭代的只是少数几个示例，因为这样能加快进度。用户对这些示例了如指掌，也能快速评估新的输出。但如果你和用户共同开发的技能只适用于这些示例，那它毫无用处。与其加入琐碎且过度拟合的修改，或施加压迫性的强制约束（MUST），不如在遇到顽固问题时尝试拓展思路，使用不同的比喻，或推荐不同的工作模式。这种尝试成本相对较低，说不定就能找到绝佳方案。

1. 保持提示简洁。 删除那些没有实际作用的内容。务必阅读完整的对话记录（transcripts），而不仅仅是最终输出——如果发现技能导致模型浪费大量时间做无用功，可以尝试移除引发这些行为的技能部分，看看效果如何。

1. 解释原因。 尽力解释你要求模型执行每项操作背后的原因。当今的大语言模型（LLM）非常聪明。它们具备良好的心智理论（theory of mind），只要给予合适的引导，就能超越机械指令，真正高效地完成任务。即使用户的反馈简短或充满挫败感，也要努力理解任务本身、用户写下这些内容的原因以及他们实际表达的意思，并将这种理解融入到指令中。如果你发现自己频繁使用全大写的 ALWAYS 或 NEVER，或采用极其僵化的结构，这就是一个警示信号——尽可能重新表述并阐明理由，让模型理解你所要求事项的重要性。这是一种更人性化、更强大且更有效的方法。

1. 寻找跨测试用例的重复工作。 阅读测试运行的对话记录，注意子代理（subagents）是否都独立编写了类似的辅助脚本，或对某些任务采取了相同的多步骤方法。如果全部 3 个测试用例都导致子代理编写了 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。其基本思路是：将两个输出提供给一个独立的代理，但不告知它哪个是哪个，由该代理判断质量优劣，然后分析胜出者胜出的原因。

此功能为可选，需要使用子代理，大多数用户并不需要。通常情况下，人工审核循环已足够。

---

描述优化

SKILL.md 文件 frontmatter 中的 description 字段是决定 Claude 是否调用该技能的主要机制。在创建或改进技能后，请主动提出优化描述，以提高触发准确率。

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

创建 20 条评估查询——包含应触发和不应触发的混合情况。保存为 JSON：

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

这些查询必须真实可信，符合 Claude Code 或 Claude.ai 用户实际会输入的内容。不要使用抽象请求，而应使用具体、明确且包含丰富细节的请求。例如，包含文件路径、用户工作或情境的个人背景、列名和值、公司名称、URL 等。可以加入少量背景故事。部分查询可以使用小写、缩写、拼写错误或口语化表达。查询长度应多样化，并聚焦于边缘情况，而非清晰明确的案例（用户后续有机会确认这些查询）。

差示例： "Format this data"、"Extract text from PDF"、"Create a chart"

好示例： "ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think"

对于 应触发 的查询（8-10 条），需考虑覆盖范围。应包含同一意图的不同表述方式——有些正式，有些随意。包括用户未明确提及技能名称或文件类型，但明显需要该技能的情况。同时加入一些不常见的用例，以及该技能与其他技能存在竞争但应胜出的情况。

对于 不应触发 的查询（8-10 条），最有价值的是“近似误触”类查询——即与技能共享关键词或概念，但实际上需要其他功能的查询。考虑相邻领域、模糊表述（若仅靠简单关键词匹配会错误触发）、以及查询内容虽涉及该技能功能，但在上下文中更适合使用其他工具的情况。

关键注意事项：避免让不应触发的查询明显无关。“Write a fibonacci function” 作为 PDF 技能的负向测试过于简单——它无法有效检验任何内容。负向案例应真正具有挑战性。

步骤 2：与用户共同审核

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

1. 从 assets/eval_review.html 读取模板
2. 替换占位符：

• __EVAL_DATA_PLACEHOLDER__ → 评估项的 JSON 数组（无需加引号——这是 JS 变量赋值）
  __SKILL_NAME_PLACEHOLDER__ → 技能名称
  __SKILL_DESCRIPTION_PLACEHOLDER__ → 技能当前描述

1. 写入临时文件（例如 /tmp/eval_review_<skill-name>.html）并打开：open /tmp/eval_review_<skill-name>.html
2. 用户可编辑查询、切换是否应触发、增删条目，然后点击“Export Eval Set”
3. 文件将下载至 ~/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> \
  --model <model-id-powering-this-session> \
  --max-iterations 5 \
  --verbose

使用系统提示中指定的模型 ID（即当前会话所用模型），以确保触发测试与用户实际体验一致。

运行过程中，定期查看输出日志，向用户更新当前迭代次数及得分情况。

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

技能触发机制的工作原理

理解触发机制有助于设计更有效的评估查询。技能会以其名称和描述的形式出现在 Claude 的 available_skills 列表中，Claude 会根据该描述决定是否调用某个技能。关键点在于：Claude 仅在自身难以轻松处理的任务上才会调用技能——像“读取此 PDF”这类简单、单步的查询，即使描述完全匹配，也可能不会触发技能，因为 Claude 可以直接使用基础工具自行处理。而复杂、多步骤或专业性强的查询，只要描述匹配，就能可靠地触发技能。

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

步骤 4：应用结果

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

---

打包并呈现（仅当 present_files 工具可用时）

检查你是否可以访问 present_files 工具。如果不可用，请跳过此步骤。如果可用，请打包该技能，并将 .skill 文件呈现给用户：

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

打包完成后，引导用户前往生成的 .skill 文件路径，以便他们安装该技能。

---

Claude.ai 特定说明

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

运行测试用例：没有子代理意味着无法并行执行。对于每个测试用例，请先读取技能的 SKILL.md，然后按照其中的说明亲自完成测试提示。一次只处理一个测试用例。这种方式不如独立子代理严谨（因为你既编写了技能又亲自运行它，拥有全部上下文），但仍可作为有用的合理性检查——人工审查步骤可弥补这一不足。跳过基线运行（baseline runs）——只需按要求使用技能完成任务即可。

审查结果：如果你无法打开浏览器（例如，Claude.ai 的虚拟机无图形界面，或你处于远程服务器上），请完全跳过浏览器审查器。改为直接在对话中呈现结果。对每个测试用例，展示提示和输出。如果输出是用户需要查看的文件（如 .docx 或 .xlsx），请将其保存到文件系统，并告知用户文件位置，以便他们下载并检查。在对话中直接征求反馈：“效果如何？有什么需要修改的吗？”

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

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

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

盲测对比：需要子代理。跳过。

打包：package_skill.py 脚本可在任何具备 Python 和文件系统的环境中运行。在 Claude.ai 上，你可以运行该脚本，用户随后可下载生成的 .skill 文件。

更新现有技能：用户可能要求你更新现有技能，而非创建新技能。此时：

• 保留原始名称。 注意技能的目录名和 name 前置元数据字段——保持不变。例如，若已安装的技能名为 research-helper，则输出 research-helper.skill（而非 research-helper-v2）。
• 编辑前先复制到可写位置。 已安装的技能路径可能是只读的。请先复制到 /tmp/skill-name/，在那里进行编辑，并从副本进行打包。
• 如果手动打包，请先暂存到 /tmp/，再复制到输出目录——直接写入可能因权限问题而失败。

---

Cowork 特定说明

如果你在 Cowork 环境中，主要需注意以下几点：

• 你拥有子代理（subagents），因此主工作流（并行生成测试用例、运行基线、评分等）均可正常运作。（不过，如果你遇到严重的超时问题，也可以选择串行而非并行地运行测试提示。）
• 你没有浏览器或显示界面，因此在生成评估查看器（eval viewer）时，请使用 --static <output_path> 参数来生成一个独立的 HTML 文件，而不是启动服务器。然后提供一个链接，供用户点击并在其浏览器中打开该 HTML 文件。
• 出于某种原因，Cowork 环境似乎会让 Claude 在运行测试后不太愿意生成评估查看器，因此这里再次强调：无论你是在 Cowork 还是 Claude Code 中，在运行测试后，你都应始终为人类用户生成评估查看器，以便他们在你自行修改技能并尝试修正之前先查看示例。请使用 generate_review.py（不要自己编写定制化的 HTML 代码）。提前说声抱歉，但我要用全大写强调：在你自己评估输入之前，务必先生成评估查看器！你要尽快把结果展示给人类用户！
• 反馈机制有所不同：由于没有运行中的服务器，查看器中的“Submit All Reviews”（提交所有评审）按钮会将 feedback.json 作为文件下载。你可以随后从该文件中读取反馈内容（你可能需要先请求访问权限）。
• 打包功能可以正常使用——package_skill.py 只需要 Python 和文件系统即可。
• 描述优化（run_loop.py / run_eval.py）在 Cowork 中应该也能正常工作，因为它通过子进程调用 claude -p，并不依赖浏览器。但请将其留到你完全完成技能开发、且用户确认技能状态良好后再执行。
• 更新现有技能：用户可能要求你更新一个已有技能，而非创建新技能。请遵循上文 Claude.ai 部分中关于更新的指导。

---

参考文件

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，协助用户审阅结果
  运行定量评估
• 反复迭代，直至你和用户均满意为止
• 打包最终技能并返回给用户

如果你有类似 TodoList 的工具，请务必添加相应步骤，以免遗忘。如果你在 Cowork 环境中，请特别将“创建 evals JSON 并运行 eval-viewer/generate_review.py，以便人类用户审阅测试用例”加入你的 TodoList，确保这一步骤得以执行。

祝你好运！