| name | skill-creator |
| description | 创建新技能、修改和改进现有技能，并衡量技能性能。当用户想要从头创建技能、编辑或优化现有技能、运行eval来测试技能、通过方差分析对技能性能进行基准测试，或优化技能描述以提高触发准确率时使用。 |
技能创建器
用于创建新技能并迭代改进的技能。
从宏观层面来看，创建技能的流程如下：
- 确定你想要技能实现的功能以及大致实现方式
- 编写技能草稿
- 创建几个测试提示词，让拥有该技能访问权限的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 frontmatter (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"这样的角色扮演技能是可以的。
编写模式
在说明中优先使用祈使句。
定义输出格式 - 你可以这样做：
## 报告结构
必须严格使用以下模板：
# [标题]
## 执行摘要
## 关键发现
## 建议
示例模式 - 包含示例很有用。你可以这样格式化示例（如果示例中包含"Input"和"Output"，你可以适当调整）：
## Commit 消息格式
**示例 1：**
Input: 新增了基于JWT令牌的用户认证
Output: feat(auth): implement JWT-based authentication
写作风格
尽量向模型解释为什么某些要求很重要，而不是生硬地使用MUST这种强制性表述。运用心智理论，尽量让技能具有通用性，不要过于局限于特定示例。先写一个草稿，然后以全新的视角审视并改进它。
测试用例
写完技能草稿后，想出2-3个符合真实用户场景的测试提示词。分享给用户：[你不需要完全照搬这句话]"这是我想尝试的几个测试用例，看起来合适吗？还是你想补充更多？"然后运行它们。
将测试用例保存到evals/evals.json。暂时不要写assertion——只保存提示词。在测试运行的过程中，你可以在下一步起草assertion。
{
"skill_name": "example-skill",
"evals": [
{
"id": 1,
"prompt": "用户的任务提示词",
"expected_output": "预期结果描述",
"files": []
}
]
}
完整的schema请参考references/schemas.md（包括稍后要添加的assertions字段）。
运行和评估测试用例
这部分是一个连续的流程——不要中途停止。不要使用/skill-test或任何其他测试技能。
将结果放在与技能目录同级的<skill-name>-workspace/目录下。在工作区内，按迭代组织结果（iteration-1/、iteration-2/等），每个测试用例有单独的目录（eval-0/、eval-1/等）。不需要预先创建所有目录——随用随建即可。
步骤1：同一轮次中启动所有运行（使用技能和基线版本）
对于每个测试用例，在同一轮次中启动两个子代理——一个使用技能，一个不使用。这一点很重要：不要先启动使用技能的运行，之后再运行基线版本。同时启动所有任务，这样它们会大致在同一时间完成。
使用技能的运行：
执行以下任务：
- 技能路径：<path-to-skill>
- 任务：<eval prompt>
- 输入文件：<如果有评估文件则列出，否则填"none">
- 输出保存到：<workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- 要保存的输出：<用户关心的内容——例如"docx文件"、"最终CSV">
基线版本运行（相同的提示词，但基线版本取决于上下文）：
- 创建新技能：完全不使用技能。相同的提示词，不指定技能路径，保存到
without_skill/outputs/。
- 改进现有技能：使用旧版本。编辑前，先对技能进行快照（
cp -r <skill-path> <workspace>/skill-snapshot/），然后让基线子代理使用快照版本。保存到old_skill/outputs/。
为每个测试用例编写eval_metadata.json（assertion暂时可以为空）。根据测试内容给每个eval起一个描述性的名称——而不只是"eval-0"。目录也使用这个名称。如果这次迭代使用了新的或修改过的评估提示词，为每个新的eval目录创建这些文件——不要假设它们会从之前的迭代继承。
{
"eval_id": 0,
"eval_name": "descriptive-name-here",
"prompt": "用户的任务提示词",
"assertions": []
}
步骤2：运行过程中起草assertion
不要只是等待运行完成——你可以有效利用这段时间。为每个测试用例起草定量assertion，并向用户解释。如果evals/evals.json中已经有assertion，检查它们并解释它们的校验内容。
好的assertion是可以客观验证的，并且具有描述性的名称——在基准查看器中应该清晰易读，让浏览结果的人一眼就能明白每个assertion检查的是什么。主观技能（写作风格、设计质量）更适合定性评估——不要强制对需要人工判断的内容使用assertion。
起草完成后，更新eval_metadata.json文件和evals/evals.json中的assertion。同时向用户说明他们在查看器中会看到什么——包括定性输出和定量基准。
步骤3：运行完成时收集耗时数据
每个子代理任务完成后，你会收到包含total_tokens和duration_ms的通知。立即将此数据保存到运行目录下的timing.json中：
{
"total_tokens": 84852,
"duration_ms": 23332,
"total_duration_seconds": 23.3
}
这是收集这些数据的唯一机会——它通过任务通知发送，不会在其他地方持久化。收到通知后立即处理，不要批量处理。
步骤4：评分、汇总并启动查看器
所有运行完成后：
-
对每个运行进行评分 —— 启动评分子代理（或直接在线评分），读取agents/grader.md并根据输出评估每个assertion。将结果保存到每个运行目录下的grading.json中。grading.json的expectations数组必须使用text、passed和evidence字段（而不是name/met/details或其他变体）——查看器依赖这些确切的字段名。对于可以通过编程方式检查的assertion，编写并运行脚本而不是人工检查——脚本更快、更可靠，并且可以在迭代中重复使用。
-
汇总到基准报告 —— 从skill-creator目录运行汇总脚本：
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
这会生成benchmark.json和benchmark.md，包含每个配置的通过率、时间和token使用情况，以及平均值±标准差和变化量。如果手动生成benchmark.json，请参考references/schemas.md查看查看器期望的确切schema。
将每个使用技能的版本放在其对应的基线版本之前。
-
分析师检查 —— 阅读基准数据，挖掘汇总统计数据可能隐藏的模式。参考agents/analyzer.md（"分析基准结果"部分）了解需要查找的内容——比如无论使用什么技能都总是通过的assertion（无区分度）、高方差的eval（可能不稳定），以及时间/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>。
Cowork/无桌面环境： 如果webbrowser.open()不可用或环境没有显示设备，使用--static <output_path>生成独立的HTML文件而不是启动服务器。当用户点击"提交所有评审"时，反馈会下载为feedback.json文件。下载后，将feedback.json复制到工作区目录，供下一次迭代使用。
注意：请使用generate_review.py创建查看器；不需要编写自定义HTML。
- 告知用户：比如"我已经在浏览器中打开了结果。有两个标签页——'输出'让你可以点击查看每个测试用例并留下反馈，'基准'展示定量对比。完成后回到这里告诉我。"
用户在查看器中看到的内容
"输出"标签页每次显示一个测试用例：
- Prompt：给出的任务
- Output：技能生成的文件，尽可能内联展示
- Previous Output（第2次及以后迭代）：折叠区域，显示上一次迭代的输出
- Formal Grades（如果运行了评分）：折叠区域，显示assertion通过/失败情况
- Feedback：文本框，输入时自动保存
- Previous Feedback（第2次及以后迭代）：用户上次的评论，显示在文本框下方
"基准"标签页显示统计摘要：每个配置的通过率、耗时和token使用情况，以及每个eval的细分和分析师观察结果。
可以通过上一个/下一个按钮或方向键导航。完成后，用户点击"提交所有评审"，所有反馈会保存到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 frontmatter中的description字段是决定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
- 用户可以编辑查询、切换是否应该触发、添加/删除条目，然后点击"导出评估集"
- 文件会下载到
~/Downloads/eval_set.json——检查Downloads文件夹中最新的版本，以防有多个文件（例如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——根据测试集分数选择而不是训练集分数，以避免过拟合。
技能触发的工作原理
理解触发机制有助于设计更好的评估查询。技能会以名称+描述的形式出现在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没有子代理，部分机制有所不同。以下是需要调整的地方：
运行测试用例：没有子代理意味着无法并行执行。对于每个测试用例，读取技能的SKILL.md，然后按照说明自己完成测试提示词的任务。逐个处理。这不如独立子代理严格（你编写了技能，同时又在运行它，所以你有完整的上下文），但这是有用的合理性检查——而且人工评审步骤可以弥补这一点。跳过基线运行——只需使用技能按要求完成任务。
评审结果：如果你无法打开浏览器（例如，Claude.ai的VM没有显示设备，或者你在远程服务器上），完全跳过浏览器评审器。相反，直接在对话中展示结果。对于每个测试用例，展示提示词和输出。如果输出是用户需要查看的文件（如.docx或.xlsx），保存到文件系统并告诉用户位置，让他们可以下载检查。直接询问反馈："看起来怎么样？有什么想修改的吗？"
基准测试：跳过定量基准测试——它依赖于基线比较，而没有子代理的话基线比较没有意义。重点关注用户的定性反馈。
迭代循环：和之前一样——改进技能，重新运行测试用例，询问反馈——只是中间没有浏览器评审器。如果有文件系统，你仍然可以将结果组织到迭代目录中。
描述优化：这部分需要claude CLI工具（特别是claude -p），只能在Claude Code中使用。如果你在Claude.ai中，跳过这部分。
盲测比较：需要子代理。跳过。
打包：package_skill.py脚本在任何有Python和文件系统的地方都可以工作。在Claude.ai中，你可以运行它，用户可以下载生成的.skill文件。
更新现有技能：用户可能要求你更新现有技能，而不是创建新技能。在这种情况下：
- 保留原始名称。注意技能的目录名和frontmatter中的
name字段——保持不变。例如，如果安装的技能是research-helper，输出research-helper.skill（而不是research-helper-v2）。
- 编辑前复制到可写位置。已安装的技能路径可能是只读的。复制到
/tmp/skill-name/，在那里编辑，然后从副本打包。
- 如果手动打包，先暂存到
/tmp/，然后复制到输出目录——直接写入可能会因为权限问题失败。
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，不需要浏览器，但请等到你完全完成技能开发并且用户确认状态良好后再进行。
- 更新现有技能：用户可能要求你更新现有技能，而不是创建新技能。按照上面claude.ai部分中的更新指南操作。
参考文件
agents/目录包含专用子代理的说明。当你需要启动相关子代理时阅读它们。
agents/grader.md — 如何根据输出评估assertionagents/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中，确保执行。
祝你好运！
