| name | skill-creator |
| description | 创建新技能、修改和改进现有技能，以及评估技能性能。当用户想要从头开始创建技能、更新或优化现有技能、运行评估来测试技能、通过方差分析对技能性能进行基准测试，或优化技能的描述以提高触发准确性时使用。 |
技能创建器
一个用于创建新技能并迭代改进它们的技能。
从高层次来看，创建技能的过程是这样的：
- 决定你想让技能做什么以及大致如何做
- 编写技能草稿
- 创建几个测试提示并在具有该技能的 claude 上运行它们
- 帮助用户定性和定量地评估结果
- 当运行在后台进行时，如果还没有定量评估就起草一些（如果已经有了，你可以直接使用或者如果觉得需要改变就修改它们）。然后向用户解释它们（或者如果它们已经存在，就解释已经存在的那些）
- 使用
eval-viewer/generate_review.py 脚本向用户展示结果供他们查看，并让他们查看定量指标
- 根据用户对结果的评估反馈（以及从定量基准中发现的任何明显缺陷）重写技能
- 重复直到满意
- 扩展测试集并在更大规模上再次尝试
使用此技能时，你的工作是弄清楚用户在这个过程中的哪个阶段，然后介入并帮助他们推进这些阶段。例如，也许他们说"我想为 X 制作一个技能"。你可以帮助缩小他们的意思，编写草稿，编写测试用例，弄清楚他们想如何评估，运行所有提示，然后重复。
另一方面，也许他们已经有了技能草稿。在这种情况下，你可以直接进入评估/迭代部分的循环。
当然，你应该始终保持灵活性，如果用户说"我不需要运行一堆评估，只需要和我一起感受一下"，你可以改为这样做。
然后在技能完成后（但同样，顺序是灵活的），你还可以运行技能描述改进器，我们为此有一个完全独立的脚本，以优化技能的触发。
明白了吗？明白了。
与用户沟通
技能创建器可能会被具有各种编程术语熟悉度的人使用。如果你没听说过（你怎么可能听说过，这是最近才开始的），现在有一个趋势，Claude 的强大功能正在激励水管工打开他们的终端，父母和祖父母去谷歌"如何安装 npm"。另一方面，大多数用户可能相当精通计算机。
因此，请注意上下文线索以了解如何表达你的沟通！在默认情况下，只是给你一些想法：
- "evaluation（评估）"和"benchmark（基准测试）"处于临界点，但可以接受
- 对于"JSON"和"assertion（断言）"，你需要从用户那里看到他们知道这些是什么的明确线索，然后才能在不解释的情况下使用它们
如果你有疑问，简要解释术语是可以的，如果你不确定用户是否理解，可以随意用简短的定义来澄清术语。
创建技能
捕获意图
首先了解用户的意图。当前对话可能已经包含用户想要捕获的工作流程（例如，他们说"把这个变成一个技能"）。如果是这样，首先从对话历史中提取答案——使用的工具、步骤顺序、用户所做的更正、观察到的输入/输出格式。用户可能需要填补空白，并在继续下一步之前确认。
- 这个技能应该使 Claude 能够做什么？
- 这个技能应该何时触发？（什么用户短语/上下文）
- 预期的输出格式是什么？
- 我们应该设置测试用例来验证技能是否有效吗？具有客观可验证输出（文件转换、数据提取、代码生成、固定工作流程步骤）的技能从测试用例中受益。具有主观输出（写作风格、艺术）的技能通常不需要它们。根据技能类型建议适当的默认值，但让用户决定。
访谈和研究
主动询问有关边缘情况、输入/输出格式、示例文件、成功标准和依赖项的问题。等到你把这部分弄清楚后再编写测试提示。
检查可用的 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): 实现基于 JWT 的身份验证
编写风格
尝试向模型解释为什么事情很重要，而不是使用重手的陈旧的 MUST。使用心智理论，尝试使技能通用，而不是超级狭窄到特定示例。首先编写草稿，然后用新鲜的眼光看它并改进它。
测试用例
编写技能草稿后，想出 2-3 个现实的测试提示——真实用户实际会说的那种话。与用户分享它们：[你不必使用这个确切的语言]"这里有几个我想尝试的测试用例。这些看起来对吗，还是你想添加更多？"然后运行它们。
将测试用例保存到 evals/evals.json。先不要编写断言——只是提示。你将在下一步中在运行进行时起草断言。
{
"skill_name": "example-skill",
"evals": [
{
"id": 1,
"prompt": "用户的任务提示",
"expected_output": "预期结果的描述",
"files": []
}
]
}
有关完整模式（包括稍后要添加的 assertions 字段），请参阅 references/schemas.md。
运行和评估测试用例
本节是一个连续的序列——不要中途停止。不要使用 /skill-test 或任何其他测试技能。
将结果放在 <skill-name>-workspace/ 中作为技能目录的同级。在工作区内，按迭代（iteration-1/、iteration-2/ 等）组织结果，在其中，每个测试用例都有一个目录（eval-0/、eval-1/ 等）。不要预先创建所有这些——只需随时创建目录。
步骤 1：在同一轮中生成所有运行（with-skill 和 baseline）
对于每个测试用例，在同一轮中生成两个子代理——一个使用技能，一个不使用。这很重要：不要先生成 with-skill 运行，然后再回来进行基线。一次性启动所有内容，以便它们大约同时完成。
With-skill 运行：
执行此任务：
- 技能路径：<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">
Baseline 运行（相同的提示，但基线取决于上下文）：
- 创建新技能：完全没有技能。相同的提示，没有技能路径，保存到
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": "用户的任务提示",
"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 期望数组必须使用字段 text、passed 和 evidence（不是 name/met/details 或其他变体）——查看器依赖于这些确切的字段名称。对于可以通过编程检查的断言，编写并运行脚本而不是目视检查——脚本更快、更可靠，并且可以在迭代中重用。
-
聚合到基准中 — 从 skill-creator 目录运行聚合脚本：
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
这将生成 benchmark.json 和 benchmark.md，其中包含每个配置的 pass_rate、time 和 tokens，以及均值 ± 标准差和增量。如果手动生成 benchmark.json，请参阅 references/schemas.md 以了解查看器期望的确切模式。
将每个 with_skill 版本放在其基线对应版本之前。
-
进行分析 — 读取基准数据并揭示聚合统计数据可能隐藏的模式。请参阅 agents/analyzer.md（"分析基准结果"部分）以了解要查找的内容——例如无论技能如何始终通过的断言（不具有区分性）、高方差评估（可能不稳定）以及时间/令牌权衡。
-
启动查看器，同时提供定性输出和定量数据：
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>。
Cowork / 无头环境： 如果 webbrowser.open() 不可用或环境没有显示，使用 --static <output_path> 写入独立的 HTML 文件而不是启动服务器。当用户点击"提交所有评论"时，反馈将作为 feedback.json 文件下载。下载后，将 feedback.json 复制到工作区目录中，以便下一次迭代可以获取。
注意：请使用 generate_review.py 创建查看器；无需编写自定义 HTML。
- 告诉用户类似这样的话："我已经在你的浏览器中打开了结果。有两个选项卡——'输出'让你点击每个测试用例并留下反馈，'基准'显示定量比较。完成后，回到这里告诉我。"
用户在查看器中看到什么
"输出"选项卡一次显示一个测试用例：
- 提示：给出的任务
- 输出：技能生成的文件，尽可能内联渲染
- 先前输出（第 2 次以上迭代）：显示上次迭代输出的折叠部分
- 正式评分（如果运行了评分）：显示断言通过/失败的折叠部分
- 反馈：一个在他们输入时自动保存的文本框
- 先前反馈（第 2 次以上迭代）：他们上次的评论，显示在文本框下方
"基准"选项卡显示统计摘要：每个配置的通过率、时间和令牌使用情况，以及每个评估的明细和分析师观察。
导航通过上一个/下一个按钮或箭头键。完成后，他们点击"提交所有评论"，将所有反馈保存到 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，如果有一些顽固的问题，你可以尝试分支并使用不同的隐喻，或推荐不同的工作模式。尝试相对便宜，也许你会找到一些很棒的东西。
-
保持提示精简。 删除没有发挥作用的东西。确保阅读记录，而不仅仅是最终输出——如果看起来技能使模型浪费了大量时间做无用的事情，你可以尝试删除技能中让它这样做的部分，看看会发生什么。
-
解释原因。 努力解释你要求模型做的每件事背后的原因。今天的 LLM 很聪明。他们有很好的心智理论，当给出一个好的工具时，可以超越死板的指令，真正让事情发生。即使用户的反馈简短或沮丧，也要尝试真正理解任务以及用户为什么写他们写的东西，以及他们实际写了什么，然后将这种理解传达到指令中。如果你发现自己用全大写写 ALWAYS 或 NEVER，或使用超级刚性的结构，这是一个黄色标志——如果可能，重新表述并解释推理，以便模型理解你要求的东西为什么重要。这是一种更人性化、更强大、更有效的方法。
-
寻找跨测试用例的重复工作。 阅读测试运行的记录，注意子代理是否都独立编写了类似的辅助脚本或采用了相同的多步骤方法来处理某些事情。如果所有 3 个测试用例都导致子代理编写了 create_docx.py 或 build_chart.py，这是一个强烈的信号，表明技能应该捆绑该脚本。写一次，放在 scripts/ 中，并告诉技能使用它。这可以节省每次未来调用重新发明轮子的时间。
这项任务非常重要（我们正在尝试每年创造数十亿的经济价值！），你的思考时间不是瓶颈；花时间真正思考。我建议编写一个草稿修订，然后重新审视它并进行改进。尽你最大的努力进入用户的头脑并理解他们想要和需要什么。
迭代循环
改进技能后：
- 将你的改进应用到技能
- 将所有测试用例重新运行到新的
iteration-<N+1>/ 目录中，包括基线运行。如果你正在创建一个新技能，基线始终是 without_skill（无技能）——跨迭代保持不变。如果你正在改进现有技能，请根据你的判断确定什么是有意义的基线：用户带来的原始版本，或先前的迭代。
- 使用
--previous-workspace 指向先前的迭代启动审阅器
- 等待用户审查并告诉你他们完成了
- 阅读新反馈，再次改进，重复
继续，直到：
- 用户说他们满意了
- 反馈全部为空（一切看起来都很好）
- 你没有取得有意义的进展
高级：盲比较
对于你想要对技能的两个版本进行更严格比较的情况（例如，用户问"新版本真的更好吗？"），有一个盲比较系统。阅读 agents/comparator.md 和 agents/analyzer.md 以获取详细信息。基本思想是：给独立代理两个输出而不告诉它哪个是哪个，让它判断质量。然后分析为什么获胜者获胜。
这是可选的，需要子代理，大多数用户不需要它。人工审查循环通常就足够了。
描述优化
SKILL.md 前言中的描述字段是决定 Claude 是否调用技能的主要机制。在创建或改进技能后，提供优化描述以提高触发准确性。
步骤 1：生成触发评估查询
创建 20 个评估查询——应该触发和不应该触发的混合。保存为 JSON：
[
{"query": "用户提示", "should_trigger": true},
{"query": "另一个提示", "should_trigger": false}
]
查询必须是现实的，并且是 Claude Code 或 Claude.ai 用户实际会输入的内容。不是抽象的请求，而是具体、特定且包含大量细节的请求。例如，文件路径、有关用户工作或情况的个人背景、列名和值、公司名称、URL。一点背景故事。有些可能是小写或包含缩写或拼写错误或随意的言语。使用不同长度的混合，并专注于边缘情况而不是使它们清晰（用户将有机会签署它们）。
不好："格式化此数据"、"从 PDF 中提取文本"、"创建图表"
好："好的，所以我的老板刚刚给我发了这个 xlsx 文件（它在我的下载中，叫做类似'Q4 sales final FINAL 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
- 用户可以编辑查询、切换 should-trigger、添加/删除条目，然后点击"导出评估集"
- 文件下载到
~/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 的 VM 没有显示，或者你在远程服务器上），完全跳过浏览器审阅器。相反，直接在对话中呈现结果。对于每个测试用例，显示提示和输出。如果输出是用户需要查看的文件（如 .docx 或 .xlsx），将其保存到文件系统并告诉他们它在哪里，以便他们可以下载和检查它。内联请求反馈："这看起来怎么样？你会改变什么吗？"
基准测试：跳过定量基准测试——它依赖于基线比较，如果没有子代理就没有意义。专注于用户的定性反馈。
迭代循环：与之前相同——改进技能，重新运行测试用例，请求反馈——只是中间没有浏览器审阅器。如果你有文件系统，你仍然可以将结果组织到迭代目录中。
描述优化：本节需要 claude CLI 工具（特别是 claude -p），它仅在 Claude Code 中可用。如果你在 Claude.ai 上，跳过它。
盲比较：需要子代理。跳过它。
打包：package_skill.py 脚本在任何有 Python 和文件系统的地方都可以工作。在 Claude.ai 上，你可以运行它，用户可以下载生成的 .skill 文件。
Cowork 特定说明
如果你在 Cowork 中，主要要知道的是：
- 你有子代理，所以主要工作流程（并行生成测试用例、运行基线、评分等）都可以工作。（但是，如果你遇到超时的严重问题，可以串行运行测试提示而不是并行。）
- 你没有浏览器或显示，所以在生成评估查看器时，使用
--static <output_path> 写入独立的 HTML 文件而不是启动服务器。然后提供用户可以点击以在浏览器中打开 HTML 的链接。
- 出于某种原因，Cowork 设置似乎使 Claude 不愿意在运行测试后生成评估查看器，所以只是重申一下：无论你是在 Cowork 还是在 Claude Code 中，在运行测试后，你应该始终生成评估查看器供人类在你自己修改技能并尝试进行更正之前查看示例，使用
generate_review.py（而不是编写你自己的精品 HTML 代码）。抱歉提前，但我要全部大写了：在自己评估输入之前生成评估查看器。你想尽快将它们放在人类面前！
- 反馈的工作方式不同：由于没有运行服务器，查看器的"提交所有评论"按钮将下载
feedback.json 作为文件。然后你可以从那里读取它（你可能需要先请求访问权限）。
- 打包有效——
package_skill.py 只需要 Python 和文件系统。
- 描述优化（
run_loop.py / run_eval.py）应该在 Cowork 中正常工作，因为它通过子进程使用 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 以帮助用户审查它们
- 运行定量评估
- 重复直到你和用户都满意
- 打包最终技能并将其返回给用户。
如果你有这样的东西，请将步骤添加到你的 TodoList 中，以确保你不会忘记。如果你在 Cowork 中，请特别将"创建评估 JSON 并运行 eval-viewer/generate_review.py 以便人类可以审查测试用例"放在你的 TodoList 中，以确保它发生。
祝好运！
