技能创建者

Skill Creator (技能创建器)

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

从高层级来看，创建技能的流程如下：

• 确定你希望技能实现的功能以及大致的实现方式

• 编写技能草案

• 创建若干测试提示词，并运行具有该技能访问权限的 Claude 来执行这些提示词

• 帮助用户从定性和定量两个维度评估结果

• 根据用户对结果的评估反馈（以及定量基准测试中显现的明显缺陷）重写技能

• 重复上述过程，直到满意为止

• 扩大测试集，并在更大规模上再次尝试

当你使用此技能时，你的任务是判断用户处于该流程的哪个阶段，然后介入并帮助他们推进。例如，如果用户说“我想做一个关于 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 (必需)
│   ├── YAML frontmatter (name, description 必需)
│   └── Markdown 指令
└── Bundled Resources (可选)
    ├── scripts/    - 用于确定性/重复性任务的可执行代码
    ├── references/ - 根据需要加载到上下文中的文档
    └── assets/     - 输出中使用的文件（模板、图标、字体）

#### 渐进式披露 (Progressive Disclosure)

技能采用三级加载系统：
1. 元数据 (name + description) - 始终在上下文中 (~100 字)
2. SKILL.md 正文 - 只要技能触发就在上下文中 (理想情况下 <500 行)
3. 捆绑资源 - 根据需要加载 (无限制，脚本无需加载即可执行)

这些字数/行数是近似值，如果需要，可以适当增加。

关键模式：

• 将 SKILL.md 控制在 500 行以内；如果接近此限制，请增加额外的层级结构，并提供清晰的指引，告知使用该技能的模型接下来应去哪里跟进。

• 在 SKILL.md 中清晰地引用文件，并指导何时阅读这些文件。

• 对于大型参考文件 (>300 行)，请包含目录。

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

cloud-deploy/
├── SKILL.md (工作流 + 选择)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

#### 无惊喜原则 (Principle of Lack of Surprise)

这是不言而喻的，但技能不得包含恶意软件、漏洞利用代码或任何可能危及系统安全的内容。技能的内容不应让用户感到意外。
如果描述了其意图，请予以考虑。不要接受创建误导性技能，或旨在实现未经授权访问、数据外泄或其他恶意活动的技能请求。不过，“扮演 XYZ 角色”之类的请求是可以接受的。

#### 写作模式

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

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

## 报告结构
始终使用此精确模板：
[标题]

执行摘要

关键发现

建议

示例模式 - 包含示例很有用。你可以这样格式化（但如果示例中已包含“输入”和“输出”，你可能需要稍作调整）：

## Commit 提交信息格式
示例 1：
输入：Added user authentication with JWT tokens
输出：feat(auth): implement JWT-based authentication

写作风格

尝试向模型解释为什么某些事项很重要，而不是生硬地使用大量的“必须（MUST）”。利用心理理论（Theory of Mind），尽量使技能具有通用性，而不是过度局限于特定示例。先写一个草稿，然后以全新的视角审视并对其进行改进。

测试用例

在完成技能草稿后，设计 2-3 个真实的测试提示词——即真实用户可能会说的话。将它们分享给用户：[不必完全使用此措辞] “这里有几个我想尝试的测试用例。这些看起来正确吗，还是您想增加更多？” 然后运行它们。

将测试用例保存到 evals/evals.json。暂时不要编写断言（assertions）——仅记录提示词。在运行过程中，你将在下一步起草断言。

{
  "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 步：在同一轮次中启动所有运行（含技能组与基准组）

对于每个测试用例，在同一轮次中启动两个子代理——一个加载技能，一个不加载。这一点至关重要：不要先启动含技能的运行，然后再回头补基准组。一次性全部启动，以便它们在相近的时间完成。

含技能运行 (With-skill run)：

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

基准运行 (Baseline run)（提示词相同，但基准取决于上下文）：

• 创建新技能：完全不使用技能。相同的提示词，无技能路径，保存至 without_skill/outputs/。

• 改进现有技能：使用旧版本。在编辑之前，对技能进行快照备份 (cp -r <skill-path> <workspace>/skill-snapshot/)，然后让基准子代理指向该快照。保存至 old_skill/outputs/。

为每个测试用例编写一个 eval_metadata.json（断言可以...
（目前为空）。为每个 eval 根据其测试内容起一个描述性的名称，而不要简单地命名为 "eval-0"。目录名称也请使用该名称。如果本次迭代使用了新的或修改后的 eval 提示词，请为每个新的 eval 目录创建这些文件——不要假设它们会从之前的迭代中继承。

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

第 2 步：在运行期间起草断言 (Assertions)

不要只是等待运行结束——你可以高效利用这段时间。为每个测试用例起草定量断言，并向用户解释。如果 evals/evals.json 中已经存在断言，请对其进行审查并解释其检查的内容。

优秀的断言应该是客观可验证且具有描述性名称的——它们在基准测试查看器 (benchmark viewer) 中应清晰易读，以便人们在浏览结果时能立即理解每个断言检查的是什么。主观技能（如写作风格、设计质量）更适合进行定性评估——不要强行将断言应用于需要人工判断的事项。

起草完成后，更新 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 或其他变体）——查看器依赖于这些精确的字段名称。对于可以通过程序检查的断言，请编写并运行脚本而非人工核对——脚本速度更快、更可靠，且可在多次迭代中重复使用。

2. 汇总至基准测试 —— 在 skill-creator 目录下运行汇总脚本：

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

3. 进行分析师审查 —— 阅读基准测试数据，挖掘汇总统计数据可能掩盖的模式。参阅 agents/analyzer.md（“分析基准测试结果”部分）了解关注重点——例如无论是否有 skill 总是通过的断言（无区分度）、高方差的 eval（可能不稳定）以及时间/token 的权衡。

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

nohup python <skill-creator-path>/eval-viewer/generate_review.py \
     <workspace>/iteration-N

对于第 2 次及之后的迭代，请同时传递 --previous-workspace <workspace>/iteration-<N-1>。

Cowork / 无头环境： 如果 webbrowser.open() 不可用或环境没有显示器，请使用 --static <output_path> 写入一个独立的 HTML 文件，而不是启动服务器。当用户点击 "Submit All Reviews" 时，反馈将作为 feedback.json 文件下载。下载后，将 feedback.json 复制到工作区目录中，以便下次迭代读取。
注意：请使用 generate_review.py 来创建查看器；无需编写自定义 HTML。
5. 告知用户类似这样的话：“我已经在浏览器中打开了结果。这里有两个标签页——‘Outputs’ 允许您点击每个测试用例并留下反馈，‘Benchmark’ 显示定量对比。完成后请回到这里告诉我。”
用户在查看器中看到的内容
“Outputs” 标签页每次显示一个测试用例：
Prompt：给出的任务

Output：技能生成的文件，尽可能内联渲染

Previous Output（第 2 次迭代+）：折叠部分，显示上次迭代的输出

Formal Grades（如果运行了评分）：折叠部分，显示断言通过/失败情况

Feedback：一个在输入时自动保存的文本框

Previous Feedback（第 2 次迭代+）：上次的评论，显示在文本框下方

“Benchmark” 标签页显示统计摘要：每个配置的通过率、耗时和 Token 使用量，以及每项评估的明细和分析师观察结果。
通过“上一个/下一个”按钮或方向键进行导航。完成后，点击 "Submit All Reviews" 将所有反馈保存到 feedback.json。
第 5 步：读取反馈
当用户告知您已完成时，读取 feedback.json：

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

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

---

改进技能
这是循环的核心。您已经运行了测试用例，用户已经审查了结果，现在您需要根据他们的反馈来优化技能。
如何思考改进方案
1. 从反馈中进行泛化。 这里的核心目标是创建能够跨多种不同 Prompt 被重复使用百万次（可能真的是百万次，甚至更多）的技能。您和用户在少数几个示例上反复迭代是为了提高速度，因为用户对这些示例了如指掌，能快速评估新输出。但如果您和用户共同开发的技能仅适用于这些示例，那么它就毫无用处。与其进行琐碎的过拟合修改或施加过于死板的强制约束（MUSTs），如果遇到顽固问题，您可以尝试尝试不同的比喻或推荐不同的工作模式。尝试的成本相对较低，而且可能会带来极佳的效果。
2. 保持提示词精简。 删除那些没有实际作用的内容。务必阅读执行日志（transcripts）而不仅仅是最终输出——如果发现某项技能导致模型在低效的任务上浪费大量时间，尝试删除该技能中引起此问题的部分，观察结果如何。
3. 解释原因。 尽量解释你要求模型执行每项操作背后的原因。如今的 LLM 非常*聪明*，它们具备良好的心理理论（theory of mind），在拥有良好的引导框架时，能够超越机械的指令真正高效地完成任务。即使用户的反馈非常简短或带有情绪，也要尝试真正理解任务本身、用户写这段话的意图以及其实际表达的内容，并将这种理解转化为指令。如果你发现自己在用大写的“ALWAYS”或“NEVER”，或者使用了极其僵化的结构，这是一个警示信号——如果可能，请重新表述并解释理由，让模型理解为什么你的要求很重要。这种方法更人性化，也更强大且有效。
4. 寻找测试用例中的重复工作。 阅读测试运行的日志，观察子代理（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 是否调用该技能的主要机制。
这是一个技能。在创建或改进技能后，请提议优化其描述，以提高触发准确率。
第一步：生成触发评估查询 (Trigger Eval Queries)
创建 20 个评估查询——包含“应触发”和“不应触发”两种类型。保存为 JSON 格式：

查询内容必须真实，且符合 Claude Code 或 Claude.ai 用户的实际输入习惯。不要使用抽象请求，而要使用具体、详细的请求。例如：包含文件路径、关于用户工作或情况的个人背景、列名和数值、公司名称、URL 等。可以加入一些背景故事。部分查询可以使用小写字母，或包含缩写、拼写错误或口语化表达。长度应多样化，且重点关注边缘案例，而非过于明确的场景（用户随后会有审核机会）。

错误示例： "格式化这些数据", "从 PDF 提取文本", "创建图表"
正确示例： "好吧，我老板刚给我发了一个 xlsx 文件（在我的下载文件夹里，文件名大概叫 'Q4 sales final FINAL v2.xlsx'），她想让我增加一列来显示利润率百分比。收入在 C 列，成本好像在 D 列"
对于 应触发 (should-trigger) 查询（8-10 个），请考虑覆盖范围。针对同一意图使用不同的表述方式——有些正式，有些随意。包含用户没有明确提及技能或文件类型但显然需要该功能的场景。加入一些不常见的用例，以及该技能与另一个技能竞争但应当胜出的场景。
对于 不应触发 (should-not-trigger) 查询（8-10 个），最有价值的是“近似错误”——即与该技能共享关键词或概念，但实际需要不同功能的查询。考虑相邻领域、简单的关键词匹配会触发但实际上不应触发的模糊表述，以及查询涉及该技能的功能但此时使用其他工具更合适的场景。
关键避免点： 不要让“不应触发”的查询显得过于无关。例如，将 "写一个斐波那契函数" 作为 PDF 技能的负面测试太简单了，无法起到测试作用。负面案例应该是真正具有挑战性的。
第二步：与用户共同审核
使用 HTML 模板向用户展示评估集以供审核：
1. 从 assets/eval_review.html 读取模板。
2. 替换占位符：
   - __EVAL_DATA_PLACEHOLDER__ $\rightarrow$ 评估项的 JSON 数组（不要加引号，这是一个 JS 变量赋值）。
   - __SKILL_NAME_PLACEHOLDER__ $\rightarrow$ 技能名称。
   - __SKILL_DESCRIPTION_PLACEHOLDER__ $\rightarrow$ 技能当前的描述。
3. 写入临时文件（例如 /tmp/eval_review_<skill-name>.html）并打开：open /tmp/eval_review_<skill-name>.html。
4. 用户可以编辑查询、切换是否应触发、添加/删除条目，然后点击 "Export Eval Set"。
5. 文件将下载到 ~/Downloads/eval_set.json —— 如果存在多个版本（如 eval_set (1).json），请检查下载文件夹中的最新版本。
这一步至关重要——糟糕的评估查询会导致糟糕的描述。
第三步：运行优化循环
告知用户：“这将需要一些时间——我将在后台运行优化循环并定期检查进度。”
将评估集保存到工作区，然后在后台运行：

<model-id-powering-this-session> \
  --max-iterations 5 \
  --verbose

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

在运行过程中，请定期追踪输出，向用户更新当前的迭代次数及评分情况。

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

Skill 触发机制详解

理解触发机制有助于设计更好的评估查询。Skill 会以“名称 + 描述”的形式出现在 Claude 的 available_skills 列表中，Claude 根据该描述决定是否调用 Skill。需要注意的是，Claude 仅在无法轻易独立处理的任务时才会调用 Skill —— 像“阅读这个 PDF”这样简单的单步查询，即使描述完全匹配，也可能不会触发 Skill，因为 Claude 可以直接通过基础工具处理。而复杂、多步骤或专业化的查询在描述匹配时能可靠地触发 Skill。

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

第 4 步：应用结果

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

---

打包与呈现（仅在 present_files 工具可用时）

检查你是否拥有 present_files 工具的访问权限。如果没有，请跳过此步骤。如果有，请打包 Skill 并向用户呈现 .skill 文件：

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

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

---

Claude.ai 特定指令

在 Claude.ai 中，核心工作流保持不变（起草 $\rightarrow$ 测试 $\rightarrow$ 评审 $\rightarrow$ 改进 $\rightarrow$ 重复），但由于 Claude.ai 没有子代理（subagents），部分机制有所变化。请按以下方式调整：

运行测试用例：没有子代理意味着无法并行执行。对于每个测试用例，请先阅读 Skill 的 SKILL.md，然后按照其指令自行完成测试提示词的任务。请逐一执行。虽然这比独立子代理的测试不够严谨（因为你既编写了 Skill 又运行它，拥有全部上下文），但它是一个有用的基本检查 —— 且可以通过人工评审步骤来弥补。跳过基准运行（baseline runs）—— 直接使用 Skill 完成请求的任务即可。

评审结果：如果你无法打开浏览器（例如 Claude.ai 的 VM 没有显示界面，或你在远程服务器上），请完全跳过浏览器评审。改为直接在对话中呈现结果。对于每个测试用例，展示提示词和输出。如果输出是用户需要查看的文件（如 .docx 或 .xlsx），请将其保存到文件系统并告知路径，以便用户下载检查。请求反馈 i
在线询问：“看起来怎么样？有什么需要修改的吗？”

基准测试 (Benchmarking)：跳过定量基准测试 —— 因为如果没有子代理 (subagents)，基准对比没有意义。重点关注用户的定性反馈。

迭代循环 (The iteration loop)：与之前相同 —— 改进技能 $\rightarrow$ 重新运行测试用例 $\rightarrow$ 请求反馈 —— 只是中间没有浏览器审核员。如果你拥有文件系统，仍然可以将结果组织在迭代目录中。

描述优化 (Description optimization)：此部分需要 claude CLI 工具（具体为 claude -p），该工具仅在 Claude Code 中可用。如果你使用的是 Claude.ai，请跳过此步。

盲测对比 (Blind comparison)：需要子代理。请跳过。

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

更新现有技能：用户可能要求你更新现有技能而非创建新技能。在这种情况下：

• 保留原名：记录技能的目录名和 name frontmatter 字段 —— 保持不变。例如，如果安装的技能是 research-helper，请输出 research-helper.skill（而非 research-helper-v2）。

• 编辑前复制到可写位置：安装的技能路径可能是只读的。请将其复制到 /tmp/skill-name/，在该处编辑，然后从副本进行打包。

• 如果手动打包，请先在 /tmp/ 中暂存，然后再复制到输出目录 —— 直接写入可能会因权限问题失败。

---

Cowork 特定指令

如果你在 Cowork 环境中，需要注意的主要事项是：

• 你拥有子代理，因此主工作流（并行生成测试用例、运行基准测试、评分等）均可正常工作。（但是，如果遇到严重的超时问题，可以将测试提示词改为串行运行而非并行。）

• 你没有浏览器或显示界面，因此在生成评估查看器 (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/ 目录包含针对专业子代理的指令。阅读 th
当你需要生成相关的子代理（subagent）时，请参考：

• agents/grader.md — 如何根据断言评估输出

• agents/comparator.md — 如何对两个输出进行盲测 A/B 对比

• agents/analyzer.md — 如何分析某个版本胜出的原因

references/ 目录包含补充文档：

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

---

再次强调核心循环流程：

• 明确技能的具体内容

• 起草或编辑技能

• 使用具备该技能的 claude 在测试提示词上运行

• 与用户共同评估输出：

• 重复上述步骤，直到你和用户都满意为止

• 打包最终技能并交付给用户

如果你有待办事项列表（TodoList），请将相关步骤添加进去以防遗漏。如果你处于 Cowork 模式，请务必在 TodoList 中加入“创建 evals JSON 并运行 eval-viewer/generate_review.py 以便人类审核测试用例”。

祝好运！