---
name: skill-creator
description: 创建新技能、修改和改进现有技能，并衡量技能表现。当用户想要从头开始创建技能、更新或优化现有技能、运行评估来测试技能、通过方差分析对技能性能进行基准测试，或优化技能描述以提高触发准确性时使用。
---

# 技能创建器

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

从高层次来看，创建技能的过程如下：

- 决定你希望技能做什么，以及它大概应该如何做
- 编写技能的草稿
- 创建几个测试提示，并对它们运行 claude-with-access-to-the-skill
- 帮助用户从定性和定量两个方面评估结果
  - 当运行在后台进行时，如果还没有定量评估，就起草一些（如果已经有，你可以直接使用，或者如果你觉得需要修改，也可以进行修改）。然后向用户解释它们（或者如果它们已经存在，就解释已有的那些）
  - 使用 `eval-viewer/generate_review.py` 脚本向用户展示结果供其查看，并让他们也看看定量指标
- 根据用户评估结果的反馈（以及定量基准测试中出现的任何明显缺陷）重写技能
- 重复此过程，直到你满意为止
- 扩大测试集并以更大规模重试

使用此技能时，你的工作是弄清楚用户处于此过程的哪个阶段，然后介入并帮助他们完成这些阶段。例如，他们可能会说“我想为 X 制作一个技能”。你可以帮助他们明确具体含义，编写草稿，编写测试用例，确定他们想如何评估，运行所有提示，然后重复。

另一方面，也许他们已经有了技能的草稿。在这种情况下，你可以直接进入循环的评估/迭代部分。

当然，你应该始终保持灵活，如果用户说“我不需要进行一堆评估，跟着感觉走就行”，你也可以这样做。

然后，在技能完成后（但再次强调，顺序是灵活的），你还可以运行技能描述改进器，我们有专门的脚本来优化技能的触发。

酷不酷？酷。

## 与用户沟通

技能创建器可能会被各种对编程术语熟悉程度不同的人使用。如果你还没听说过（你怎么可能听说过呢，这才是最近才开始的），现在有一种趋势，即 Claude 的强大能力正激励着水管工打开他们的终端，父母和祖父母去谷歌“如何安装 npm”。另一方面，大多数用户可能对计算机有相当的了解。

所以请注意上下文线索，以了解如何组织你的沟通语言！在默认情况下，为了给你一些概念：

- “evaluation” (评估) 和 “benchmark” (基准测试) 处于临界点，但可以使用
- 对于 “JSON” 和 “assertion” (断言)，你需要从用户那里看到明确的信号，表明他们知道这些是什么，然后才能在不解释的情况下使用它们

如果你不确定，可以简要解释术语，如果你不确定用户是否会理解，可以随时用简短的定义来澄清术语。

---

## 创建一个技能

### 捕获意图

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

1. 这个技能应该让 Claude 能做什么？
2. 这个技能应该在什么时候触发？（哪些用户短语/上下文）
3. 预期的输出格式是什么？
4. 我们是否应该设置测试用例来验证技能是否有效？具有客观可验证输出（文件转换、数据提取、代码生成、固定的工作流步骤）的技能会从测试用例中受益。具有主观输出（写作风格、艺术）的技能通常不需要它们。根据技能类型建议合适的默认选项，但让用户做决定。

### 访谈与研究

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

检查可用的 MCPs - 如果对研究有用（搜索文档、寻找相似技能、查找最佳实践），如果可用，则通过子代理并行研究，否则内联研究。做好准备，带上上下文，以减轻用户的负担。

### 编写 SKILL.md

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

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

### 技能编写指南

#### 技能的剖析

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

#### 渐进式披露

技能使用三级加载系统：
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

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

#### 无意外原则

这是不言而喻的，但技能不能包含恶意软件、漏洞利用代码或任何可能危及系统安全的内容。技能的内容不应在使用时出乎用户的意料。不要同意创建误导性技能或旨在促进未经授权的访问、数据泄露或其他恶意活动的技能的请求。不过，像“扮演一个 XYZ”这样的角色扮演是可以的。

#### 编写模式

在指令中倾向于使用祈使句式。

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

报告结构

始终使用这个确切的模板：

[标题]

执行摘要

主要发现

建议

**示例模式** - 包含示例很有用。你可以这样格式化它们（但如果“Input”和“Output”在示例中，你可能需要稍微偏离一下）：

提交信息格式

示例 1: 输入: Added user authentication with JWT tokens 输出: feat(auth): implement JWT-based authentication

### 写作风格

尝试向模型解释事情为什么重要，而不是使用强硬的、必须遵守的“必须（MUST）”。运用心智理论，努力使技能具有通用性，而不是局限于非常狭窄的例子。先写一个草稿，然后用全新的眼光审视并改进它。

### 测试用例

编写技能草稿后，想出 2-3 个真实的测试提示——那种真实用户会说的话。与用户分享它们：[你不必使用这个确切的语言] “这里有几个我想尝试的测试用例。这些看起来对吗，或者你想添加更多？”然后运行它们。

将测试用例保存到 `evals/evals.json`。暂时不要写断言（assertions）——只写提示。你将在下一步骤中，在运行进行时起草断言。

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

请参阅 `references/schemas.md` 查看完整模式（包括 `assertions` 字段，你稍后会添加）。

## 运行和评估测试用例

这一节是一个连续的序列——不要中途停止。不要使用 `/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/
• 要保存的输出: <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": "用户的任务提示", "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` 或其他变体）——查看器依赖于这些确切的字段名。对于可以通过编程检查的断言，编写并运行一个脚本，而不是目测——脚本更快、更可靠，并且可以在迭代中重用。

2. **聚合成基准** — 从 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 版本放在其基准对应版本之前。

3. **进行分析师审查** — 阅读基准数据并揭示聚合统计数据可能隐藏的模式。请参阅 `agents/analyzer.md`（“分析基准结果”部分）以了解要查找的内容——例如无论技能如何都总是通过的断言（非区分性）、高方差评估（可能不稳定）以及时间和令牌的权衡。

4. **启动带有定性输出和定量数据的查看器**：

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。

5. **告诉用户** 类似这样的话：“我已在你的浏览器中打开了结果。有两个选项卡——‘Outputs’让你点击浏览每个测试用例并留下反馈，‘Benchmark’显示定量比较。完成后，请回到这里告诉我。”

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

“Outputs” 选项卡一次显示一个测试用例：
- **Prompt**: 给出的任务
- **Output**: 技能生成的文件，尽可能内联渲染
- **Previous Output** (迭代 2+)：显示上次迭代输出的折叠部分
- **Formal Grades** (如果进行了评分)：显示断言通过/失败的折叠部分
- **Feedback**: 一个文本框，输入时会自动保存
- **Previous Feedback** (迭代 2+)：他们上次的评论，显示在文本框下方

“Benchmark” 选项卡显示统计摘要：每个配置的通过率、时间和令牌使用情况，以及每个评估的分解和分析师观察。

通过上一个/下一个按钮或箭头键进行导航。完成后，他们点击“Submit All Reviews”，这将所有反馈保存到 `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

---

## 改进技能

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

### 如何思考改进

1. **从反馈中归纳。** 这里发生的大事是，我们正在努力创造可以被使用一百万次（也许是字面上的，也许更多谁知道呢）的技能，跨越许多不同的提示。在这里，你和用户只是一遍又一遍地对几个例子进行迭代，因为这有助于加快速度。用户对这些例子了如指掌，评估新输出对他们来说很快。但是，如果你和用户共同开发的技能只对那些例子有效，那它就毫无用处。与其进行繁琐的、过拟合的更改，或施加压迫性的、限制性的“必须（MUST）”，如果存在一些顽固的问题，你可以尝试拓展思路，使用不同的比喻，或推荐不同的工作模式。尝试的成本相对较低，也许你会发现一些很棒的东西。

2. **保持提示精简。** 删除那些不起作用的东西。确保阅读对话记录，而不仅仅是最终输出——如果看起来技能让模型浪费大量时间做一些没有成效的事情，你可以尝试去掉那些让它这样做的技能部分，看看会发生什么。

3. **解释原因。** 努力解释你要求模型做的每件事背后的**原因**。今天的 LLM 非常*聪明*。它们有很好的心智理论，当给予良好的驾驭时，可以超越死记硬背的指令，真正地办成事情。即使用户的反馈很简洁或令人沮丧，也要尝试真正理解任务以及用户为什么写了他们所写的东西，以及他们实际写了什么，然后将这种理解传递到指令中。如果你发现自己用全大写写 ALWAYS 或 NEVER，或使用超严格的结构，那是一个黄旗——如果可能的话，重新组织语言并解释原因，以便模型理解你要求的事情为什么重要。这是一种更人性化、更强大、更有效的方法。

4. **在测试用例中寻找重复的工作。** 阅读测试运行的记录，注意子代理是否都独立地编写了类似的辅助脚本或对某件事采取了相同的多步方法。如果所有 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": "用户提示", "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 模板向用户展示评估集以供审查：

1. 从 `assets/eval_review.html` 读取模板
2. 替换占位符：
   - `__EVAL_DATA_PLACEHOLDER__` → eval 项的 JSON 数组（周围不要加引号——它是一个 JS 变量赋值）
   - `__SKILL_NAME_PLACEHOLDER__` → 技能的名称
   - `__SKILL_DESCRIPTION_PLACEHOLDER__` → 技能当前的描述
3. 写入一个临时文件（例如，`/tmp/eval_review_<skill-name>.html`）并打开它：`open /tmp/eval_review_<skill-name>.html`
4. 用户可以编辑查询、切换 should-trigger、添加/删除条目，然后点击“导出评估集”
5. 文件会下载到 `~/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——通过测试分数而不是训练分数来选择，以避免过拟合。

### 技能触发如何工作

理解触发机制有助于设计更好的评估查询。技能以其名称+描述出现在 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 的虚拟机没有显示器，或者你在远程服务器上），完全跳过浏览器审查器。而是在对话中直接呈现结果。对于每个测试用例，显示提示和输出。如果输出是用户需要查看的文件（如 .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-with-access-to-the-skill
- 与用户一起评估输出：
  - 创建 benchmark.json 并运行 `eval-viewer/generate_review.py` 以帮助用户审查它们
  - 运行定量评估
- 重复直到你和用户都满意为止
- 打包最终的技能并将其返回给用户。

请将步骤添加到你的 TodoList（如果你有这样的东西），以确保你不会忘记。如果你在 Cowork 中，请特别将“创建 evals JSON 并运行 `eval-viewer/generate_review.py` 以便人类可以审查测试用例”放入你的 TodoList，以确保它会发生。

祝你好运！