skill-creator

name	skill-creator
description	创建新技能、修改并改进现有技能，并衡量技能表现。当用户想从零创建技能、编辑/优化已有技能、运行评测（evals）测试技能、用方差分析做基准测试（benchmark）、或优化技能描述以提升触发准确率时使用。

Skill Creator（技能创建器）

用于创建新技能并进行迭代改进的技能。

从宏观上看，创建技能的流程大致如下：

• 明确你希望这个技能做什么，以及大概怎么做
• 写出技能的初稿
• 准备一些测试提示词，并用带技能的运行（claude-with-access-to-the-skill）执行
• 帮助用户从定性与定量两个维度评估结果
  • 在后台运行期间，如果还没有定量评测，就先起草一些（如果已有，可以直接使用或按需修改），并向用户解释这些评测（或解释现有评测）
  • 使用 eval-viewer/generate_review.py 把结果展示给用户，同时让用户查看定量指标
• 根据用户评审反馈（以及基准测试中暴露的明显问题）重写/改写技能
• 重复迭代直到满意
• 扩大测试集规模，再做一次更大范围的验证

使用本技能时，你的工作是判断用户处于上述流程的哪一步，然后介入并推动他们向下一阶段推进。例如用户说“我想做一个用于 X 的技能”，你可以帮助澄清需求、写初稿、写测试用例、确定评估方式、跑完全部测试提示词，并据此反复迭代。

反过来，如果用户已经有技能初稿，你可以直接进入“评测/迭代”环节。

当然你需要保持灵活：如果用户说“我不需要跑一堆评测，咱们先凭感觉一起改”，也可以按用户偏好走。

技能完成后（顺序也可灵活调整），你还可以运行“技能描述优化器”（我们有单独的脚本）来优化技能的触发效果。

可以吧？那就开始。

与用户沟通

Skill Creator 可能会被“对编程术语熟悉程度差异很大”的人使用。现在有一种趋势：模型能力让很多非技术用户也开始打开终端、搜索“如何安装 npm”。当然，也有相当一部分用户是比较懂电脑/软件的。

因此请根据上下文线索调整你的表达方式。默认情况下，大致可参考：

• “evaluation（评测）”“benchmark（基准测试）”算是边缘术语，但一般可以接受
• 对 “JSON”“assertion（断言）” 这类更技术化的词，只有在你从用户表述中明确看出他们懂时，才可以不解释直接使用

如果你不确定用户是否理解某个术语，简要解释是可以的；也可以用一句短定义来澄清含义。

---

创建技能

捕捉意图（Capture Intent）

从理解用户意图开始。当前对话里可能已经包含用户想“固化为技能”的流程（例如用户说“把这个做成技能”）。如果是这种情况，先从对话历史里提取关键信息：用到哪些工具、步骤顺序、用户做过哪些纠正、观察到的输入/输出格式等。用户可能需要补齐缺口；在进入下一步前应先确认这些信息。

1. 这个技能应该让 Claude 能做什么？
2. 这个技能应在什么情况下触发？（用户的哪些表述/上下文）
3. 期望的输出格式是什么？
4. 是否需要建立测试用例来验证技能有效？对“可客观验证输出”的技能（文件转换、数据抽取、代码生成、固定流程步骤）测试用例很有价值；对“主观输出”的技能（写作风格、美术）通常不一定需要。你可以根据技能类型给出默认建议，但让用户做最终决定。

访谈与调研（Interview and Research）

主动询问边界情况、输入/输出格式、示例文件、成功标准以及依赖项等。在这些关键点明确之前，不要急着写测试提示词。

检查可用的 MCP：如果对研究有帮助（查文档、找类似技能、查最佳实践），在有子代理的情况下尽量并行研究；否则就直接在当前对话内完成。准备好上下文，尽量减少用户负担。

编写 SKILL.md

基于用户访谈，补全以下部分：

• name：技能标识符
• description：何时触发、做什么。这是最主要的触发机制——既要描述技能能做什么，也要写清楚在什么具体语境下使用。“何时使用”的信息都应写在这里，而不是写在正文里。注意：目前模型倾向于“触发不足”（明明该用技能却没用）。为对抗这一点，请把描述写得稍微“更主动一点”。例如，不要只写“如何构建一个简单快速的仪表盘展示公司内部数据”，而可以写“如何构建一个简单快速的仪表盘展示公司内部数据。只要用户提到仪表盘、数据可视化、内部指标、或想展示任何公司数据，即使没明确说要‘仪表盘’，也要使用本技能。”
• compatibility：所需工具、依赖（可选，通常很少需要）
• 技能正文其他部分 :)

技能写作指南

技能的目录结构（Anatomy of a Skill）

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)

渐进式披露（Progressive Disclosure）

技能采用三层加载机制：

1. 元数据（name + description）：始终在上下文中（约 100 词量级）
2. SKILL.md 正文：技能触发时加载进上下文（理想情况下 <500 行）
3. 随附资源：按需加载（不受限制；脚本可直接执行而无需全文加载）

上述字数/行数只是粗略指导，必要时可以更长。

关键模式：

• SKILL.md 尽量控制在 500 行以内；接近上限时，增加一层层级结构，并明确告诉使用该技能的模型接下来该去哪里继续阅读/跟进
• 在 SKILL.md 中清晰引用其他文件，并说明何时需要读取
• 对较大的参考文件（>300 行）提供目录

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

cloud-deploy/
├── SKILL.md (workflow + selection)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

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

“不意外”原则（Principle of Lack of Surprise）

不言自明：技能不得包含恶意软件、漏洞利用代码或任何可能危害系统安全的内容。技能的内容不应在“其描述的意图”层面上让用户感到意外。不要配合创建误导性技能，或用于未授权访问、数据外传等恶意活动的技能。但像“扮演某个角色进行对话”的需求通常是可以的。

写作模式（Writing Patterns）

指令中优先使用祈使句（imperative form）。

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

## Report structure
ALWAYS use this exact template:
# [Title]
## Executive summary
## Key findings
## Recommendations

示例模式：包含例子通常很有用，可以这样组织（如果例子里包含 “Input/Output” 可能需要稍作变化）：

## Commit message format
**Example 1:**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication

写作风格（Writing Style）

尽量用“解释为什么重要”的方式替代生硬的 MUST/强制口吻。运用“换位思考”，让技能更通用，而不是过度依赖某个特定例子。先写初稿，再用“新鲜视角”回看并改进。

测试用例（Test Cases）

写完技能初稿后，提出 2-3 个真实的测试提示词——要像真实用户会说的话。把它们展示给用户（不必逐字照抄）：“我想试几条测试用例，你看是否合适？要不要再加一些？”然后执行这些测试。

把测试用例保存到 evals/evals.json。先不要写断言（assertions）——只写 prompts。下一步在运行进行时再起草断言。

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "User's task prompt",
      "expected_output": "Description of expected result",
      "files": []
    }
  ]
}

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

运行并评估测试用例

这一节是一段连续流程——不要中途停下来。不要使用 /skill-test 或任何其他测试类技能。

把结果放在 <skill-name>-workspace/（与技能目录同级）。在 workspace 中按迭代组织（iteration-1/、iteration-2/…），每个测试用例再单独建目录（eval-0/、eval-1/…）。不要一次性把所有目录都预创建——边跑边建即可。

Step 1：在同一轮启动所有运行（with-skill 与 baseline）

对每个测试用例，在同一轮里启动两个子代理——一个“带技能”，一个“基线（不带）”。这一点很重要：不要先跑带技能的，再回头跑基线；要一次性全启动，让它们尽量在相近时间完成。

带技能（With-skill）运行：

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">

基线（Baseline）运行（同样 prompt，但基线取决于场景）：

• 创建新技能：完全不使用技能。prompt 相同、不提供 skill path，输出保存到 without_skill/outputs/。
• 改进已有技能：使用旧版本。编辑前先对技能做快照（cp -r <skill-path> <workspace>/skill-snapshot/），再让基线子代理指向该快照。输出保存到 old_skill/outputs/。

为每个测试用例写一个 eval_metadata.json（暂时可以让 assertions 为空）。根据“它在测什么”给每个 eval 取一个描述性名称，而不是只叫 “eval-0”；目录名也用这个名称。如果本次迭代使用了新的或修改过的 eval prompts，就为每个新的 eval 目录创建这些文件——不要假设它们会从上一轮自动沿用。

{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "The user's task prompt",
  "assertions": []
}

Step 2：运行进行时起草断言（assertions）

不要只是等运行结束——可以利用这段时间做更有价值的事：为每个测试用例起草定量断言，并向用户解释这些断言。如果 evals/evals.json 里已经有断言，就复查并说明它们在检查什么。

好的断言应当可客观验证，并且名称具有描述性——在 benchmark viewer 中一眼就能看出它在检查什么。对偏主观的技能（写作风格、设计质量）更适合定性评估，不要把需要人工判断的东西硬塞进断言里。

断言起草完成后，更新各个 eval_metadata.json 以及 evals/evals.json。同时向用户说明在 viewer 里会看到什么——包括定性输出与定量 benchmark。

Step 3：运行完成时记录耗时数据（timing）

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

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

这是捕获该数据的唯一机会——它只会出现在任务通知中，不会在别处持久化。建议按通知到达顺序逐条处理，不要想着最后再批量补。

Step 4：打分、聚合，并启动 viewer

当所有运行都完成后：

1. 给每次运行打分：启动 grader 子代理（或直接在当前对话内评分），读取 agents/grader.md，对照输出评估每条断言。将结果保存到每个运行目录的 grading.json。grading.json 的 expectations 数组字段必须使用 text、passed、evidence（不要用 name/met/details 等其他变体）——viewer 依赖这些字段名。对可编程验证的断言，优先写脚本运行校验，而不是目测；脚本更快、更可靠，还能复用。

2. 聚合为 benchmark：在 skill-creator 目录下运行聚合脚本：

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

   这会生成 benchmark.json 和 benchmark.md，包含每种配置的 pass_rate、耗时与 tokens（均值 ± 标准差，以及差值 delta）。如果要手工生成 benchmark.json，请参考 references/schemas.md 中 viewer 期望的精确 schema。

   请把每个 with_skill 版本放在它的 baseline 版本之前。

3. 做一次分析师（analyst）复盘：阅读 benchmark 数据，挖掘聚合统计可能掩盖的模式。看 agents/analyzer.md（“Analyzing Benchmark Results” 部分）了解要关注的点，例如：不区分好坏的断言（总是通过）、高方差 eval（可能不稳定/易抖动）、耗时/耗 token 的权衡等。

4. 启动 viewer（同时提供定性输出与定量数据）：

   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=$!
   

   从 iteration 2 开始，还要传 --previous-workspace <workspace>/iteration-<N-1>。

   Cowork / 无界面环境：如果无法使用 webbrowser.open() 或环境没有显示器，用 --static <output_path> 生成一个独立 HTML 文件，而不是启动服务器。用户点击 “Submit All Reviews” 后会下载 feedback.json；下载后把它复制到 workspace 目录，供下一轮迭代读取。

注意：请使用 generate_review.py 来创建 viewer；无需自写 HTML。

5. 提示用户如何使用：例如告诉用户：“我已经在浏览器里打开结果。这里有两个标签页：‘Outputs’ 可以逐条查看测试用例并写反馈，‘Benchmark’ 展示定量对比。你看完后回到这里告诉我即可。”

用户在 viewer 里会看到什么

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

• Prompt：给出的任务
• Output：技能生成的文件（尽可能内联渲染）
• Previous Output（iteration 2+）：折叠区展示上一轮输出
• Formal Grades（若已打分）：折叠区展示断言通过/失败
• Feedback：输入框，输入时自动保存
• Previous Feedback（iteration 2+）：上一轮的评论，显示在输入框下方

“Benchmark” 标签页展示统计摘要：每种配置的通过率、耗时与 token 使用，并提供按 eval 的拆解和分析观察。

可通过上一页/下一页按钮或方向键导航。完成后用户点击 “Submit All Reviews”，会把所有反馈保存为 feedback.json。

Step 5：读取反馈（feedback.json）

用户告知完成评审后，读取 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

---

改进技能（Improving the skill）

这是迭代循环的核心：你已经跑了测试用例，用户也评审了结果，现在需要根据反馈让技能变得更好。

如何思考改进方向

1. 从反馈中抽象出可泛化的规律。 核心目标是做出“可被反复使用很多次”的技能，能覆盖不同提示词。你和用户之所以反复在少数例子上迭代，是因为速度快、用户也更熟悉这些例子，便于快速评估。但如果最终技能只能在这些例子上工作，那就没有价值。相比加入琐碎的过拟合修补或极其压迫的 MUST，遇到顽固问题时不妨尝试更换隐喻/表述方式，或推荐不同的工作模式；试错成本相对低，可能会找到更好的方案。

2. 保持提示词精炼。 删除不“值回票价”的内容。一定要看运行转录（transcripts），而不仅是最终输出——如果技能让模型把大量时间浪费在无产出的步骤上，尝试删掉促使它这么做的部分，看会发生什么。

3. 解释“为什么”。 尽量解释你要求模型做每件事背后的原因。如今的 LLM 很聪明，有很强的“换位理解”能力，给到合适的约束与动机，它往往能超越死板指令真正把事情办成。即使用户反馈很短或带情绪，也要努力理解任务与用户话语背后的动机，并把这种理解转译到指令里。如果你发现自己在大写写 ALWAYS/NEVER 或用非常僵硬的结构，那是个黄灯信号——尽量改为解释理由，让模型知道为什么这件事重要；这通常更人性、更强大，也更有效。

4. 寻找跨测试用例的重复劳动。 阅读测试运行的 transcripts，观察子代理是否都在独立地写类似的辅助脚本，或对同一类问题都采取了相同的多步方案。如果 3 个测试用例里都出现子代理写 create_docx.py 或 build_chart.py，这是强信号：技能应当把该脚本打包。把脚本写一次放进 scripts/，并在技能中指引去使用它，能避免后续调用重复造轮子。

这件事很重要（我们是在尝试创造巨大的经济价值），你的思考时间不是瓶颈；请认真琢磨。可以先写一版改动，再过一遍用“新鲜视角”去改进。

迭代循环

改进技能后：

1. 把改动应用到技能上
2. 把所有测试用例重跑到新的 iteration-<N+1>/ 目录里（包括 baseline）。如果是在创建新技能，baseline 永远是 without_skill（不带技能）——各轮都一致。如果是在改进已有技能，baseline 取决于你的判断：可能是用户带来的原始版本，也可能是上一轮版本。
3. 用 --previous-workspace 指向上一轮目录，启动 reviewer
4. 等用户评审并告知完成
5. 读新反馈、继续改进、重复

持续迭代直到：

• 用户表示满意
• 反馈全部为空（看起来都很好）
• 你已经很难继续做出有意义的改进

---

高级：盲测对比（Blind comparison）

当你需要对两个版本的技能做更严格的比较（例如用户问“新版本真的更好吗？”）时，可以使用盲测比较系统。细节见 agents/comparator.md 和 agents/analyzer.md。基本思路是：把两份输出交给一个独立代理，不告诉它哪份来自哪个版本，让它判断质量；再分析胜者为何胜出。

这一步是可选的，需要子代理，多数用户并不需要。通常人工评审循环已足够。

---

描述优化（Description Optimization）

SKILL.md frontmatter 中的 description 字段是决定模型是否调用技能的关键机制。创建或改进技能后，可以主动提出：优化 description 以提升触发准确率。

Step 1：生成触发评测 queries

创建 20 条评测 queries——应当混合 should-trigger 与 should-not-trigger。保存为 JSON：

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

这些 queries 必须真实，像 Claude Code 或 Claude.ai 用户真的会输入的内容；不要抽象请求，而要具体、细节充分。例如包含文件路径、用户工作/处境的个人背景、列名和值、公司名、URL 等；可以带一点背景故事。有些可以全小写、包含缩写、拼写错误或口语表达。长度要有混合，并重点覆盖边界情况，而不是把正负样本写得过于“显而易见”（用户后续会审核并签字确认）。

Bad: "Format this data", "Extract text from PDF", "Create a chart"

Good: "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"

对 should-trigger（8-10 条），关注覆盖面：同一意图用不同说法表达（正式/随意皆有）。要包含“用户没明确提技能或文件类型，但明显需要它”的情况；也可加入一些不常见用例，以及“该技能与其他技能存在竞争但应当胜出”的用例。

对 should-not-trigger（8-10 条），最有价值的是“近似误触发”样本：它们与技能共享关键词/概念，但实际需要的是别的东西。考虑相邻领域、容易被简单关键词匹配误触发的歧义表述，以及“涉及技能能力但在该上下文里更适合用别的工具/技能”的情况。

最需要避免的是：不要把 should-not-trigger 写得明显无关。比如用“写一个斐波那契函数”来作为 PDF 技能的负样本太简单，测不出什么。负样本应当足够“刁钻”，才能真正检验描述的鲁棒性。

Step 2：与用户一起复查

使用 HTML 模板把 eval 集呈现给用户复查：

1. 从 assets/eval_review.html 读取模板
2. 替换占位符：
   • __EVAL_DATA_PLACEHOLDER__ → eval items 的 JSON 数组（不要加引号——它是 JS 变量赋值）
   • __SKILL_NAME_PLACEHOLDER__ → 技能名称
   • __SKILL_DESCRIPTION_PLACEHOLDER__ → 当前技能描述
3. 写入临时文件（如 /tmp/eval_review_<skill-name>.html）并打开：open /tmp/eval_review_<skill-name>.html
4. 用户可编辑 queries、切换 should-trigger、增删条目，然后点击 “Export Eval Set”
5. 文件会下载到 ~/Downloads/eval_set.json ——如果有多个版本（如 eval_set (1).json），注意取最新

这一步很关键——差的 eval queries 会导向差的描述。

Step 3：运行优化循环

告知用户：“这会花一点时间——我会在后台跑优化循环，并定期查看进度。”

把 eval 集保存到 workspace，然后在后台运行：

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

--model 使用系统提示词里显示的模型 ID（当前会话所用模型），确保触发测试与用户真实体验一致。

运行期间，定期查看输出，向用户同步当前迭代轮次与分数情况。

该脚本会自动跑完整的优化循环：将 eval 集按 60% 训练 / 40% 留出测试划分，评估当前 description（每条 query 运行 3 次以获得更稳定的触发率），再让模型基于失败项提出改进建议；对每个新描述同时在训练集与测试集上复评，最多迭代 5 次。结束后会在浏览器打开 HTML 报告展示每轮结果，并输出包含 best_description 的 JSON（按测试集分数选择，而非训练集分数，以避免过拟合）。

技能触发机制说明

理解触发机制有助于设计更好的 eval queries。技能会以 name + description 出现在 available_skills 列表中，模型会基于 description 决定是否读取该技能。关键点是：模型通常只会在“它靠自己不太容易直接完成”的任务上去查询技能——像“读一下这个 PDF”这类一步请求，即使描述完全匹配也可能不触发，因为模型觉得用基础工具就能做。复杂、多步或更专业的请求在描述匹配时更容易稳定触发技能。

因此你的 eval queries 应该足够“有内容”，让模型确实能从查阅技能中获益。像“读取文件 X”这种简单请求是糟糕的测试用例——无论描述写得多好，它们往往都不会触发技能。

Step 4：应用结果

从 JSON 输出中取 best_description，更新技能的 SKILL.md frontmatter。向用户展示 before/after，并汇报分数。

---

打包与交付（仅当存在 present_files 工具时）

检查你是否能使用 present_files 工具；如果没有，跳过。如果可以，将技能打包并交付给用户：

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

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

---

Claude.ai 专用说明

在 Claude.ai 中，核心流程相同（起草 → 测试 → 评审 → 改进 → 重复），但因为没有子代理，一些机制需要调整：

运行测试用例：没有子代理就无法并行执行。对每条测试用例，先读技能的 SKILL.md，然后你自己按指令完成该提示词；一次只做一个。它不如独立子代理严格（你既写技能又跑技能，拥有完整上下文），但作为 sanity check 很有用，而且人工评审能补足。可以跳过基线运行——直接用技能完成任务即可。

评审结果：如果无法打开浏览器（例如 VM 无显示器、或远程服务器），就跳过浏览器 reviewer，直接在对话里展示结果：对每个测试用例给出 prompt 与输出。如果输出是用户需要下载查看的文件（如 .docx、.xlsx），把文件保存到文件系统并告诉用户路径，便于下载检查。再在对话里询问反馈：“看起来怎么样？有什么要改的吗？”

基准测试：跳过定量 benchmark——它依赖基线对照，没有子代理时意义不大。聚焦用户的定性反馈即可。

迭代循环：与之前相同——改进技能、重跑测试、收集反馈——只是中间不再用浏览器 reviewer。如果你有文件系统，也可以继续按 iteration 目录组织结果。

描述优化：这一节需要 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/ staging：再复制到输出目录——直接写可能因为权限失败。

---

Cowork 环境说明

如果你在 Cowork 环境里，主要注意：

• 你有子代理，因此主流程（并行启动测试、跑基线、打分等）都可用。（若遇到严重超时，也可以改成串行执行。）
• 你没有浏览器/显示器，因此生成 eval viewer 时用 --static <output_path> 输出独立 HTML，而不是启动服务器；用户提交反馈会下载 feedback.json，你需要把它复制回 workspace。
• 不知为何，Cowork 环境似乎会让模型不太愿意在跑完测试后生成 eval viewer。再次强调：无论在 Cowork 还是 Claude Code，跑完测试后都应当先用 generate_review.py 生成 eval viewer 给人类看例子，然后再自己评估并改技能（不要自己写一套“定制 HTML”）。提前说声抱歉，这里要用大写强调：在你自己评估输入之前，先生成 eval viewer。要尽快把样例交给人类评审！
• 反馈机制不同：没有服务器时，“Submit All Reviews” 会下载 feedback.json。你可能需要先请求访问，然后再读取它。
• 打包可用：package_skill.py 只需要 Python 和文件系统。
• 描述优化（run_loop.py / run_eval.py）在 Cowork 理论上可用，因为它通过 subprocess 调用 claude -p 而非浏览器；但请在你完全完成技能、且用户认可已成型后再做。
• 更新现有技能：按照上面 Claude.ai 部分的“更新指导”操作。

---

参考文件（Reference files）

agents/ 目录包含专用子代理的说明；当你需要启动对应子代理时读取相关文件。

• agents/grader.md — 如何对照输出评估断言
• agents/comparator.md — 如何对两份输出做盲测 A/B 对比
• agents/analyzer.md — 如何分析为什么某版本胜出

references/ 目录包含补充文档：

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

---

最后再重复一遍核心循环（强调）：

• 明确技能目标
• 起草或编辑技能
• 用测试提示词运行（带技能）
• 与用户一起评估输出：
  • 生成 benchmark.json 并运行 eval-viewer/generate_review.py 让用户评审
  • 运行定量评测
• 重复迭代直到满意
• 打包最终技能并交付给用户

如果你有待办清单，请把关键步骤写进去以免遗漏。若在 Cowork 环境，请务必把“创建 evals JSON 并运行 eval-viewer/generate_review.py 让人类评审测试用例”明确写入待办，确保真的会做。

祝你好运！