skill-creator

技能创建器

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

从总体上看，创建技能的流程如下：

• 确定你希望技能实现什么，以及大致该如何实现
• 编写技能草稿
• 创建几个测试提示词，并让可使用该技能的 Agent 运行这些提示词
• 帮助用户从定性和定量两方面评估结果
  • 在后台运行测试时，如果还没有定量评估，就先起草一些；如果已有评估，可以直接使用，也可以在认为需要调整时进行修改。然后向用户说明这些评估（如果已有评估，则说明现有评估）
  • 使用 eval-viewer/generate_review.py 脚本向用户展示结果供其查看，同时让用户查看定量指标
• 根据用户对结果的评估反馈重写技能（如果定量基准测试暴露出明显缺陷，也要据此改进）
• 重复以上步骤，直到满意为止
• 扩充测试集，并再次进行更大规模的测试

使用此技能时，你的任务是判断用户目前处于流程的哪个阶段，并帮助他们推进后续步骤。例如，用户可能会说“我想为 X 创建一个技能”。你可以帮他们明确需求、编写草稿、编写测试用例、确定评估方式、运行所有提示词，并反复迭代。

另一方面，用户可能已经有了技能草稿。这时，你可以直接进入评估和迭代环节。

当然，你应该始终保持灵活。如果用户说“我不需要进行一大堆评估，随便和我聊聊就行”，那就照做。

技能完成后（不过顺序可以灵活调整），你还可以运行技能描述优化器，优化技能的触发方式；我们有一个单独的脚本可以完成这件事。

明白了吗？明白了。

与用户沟通

技能创建器可能会被编程术语熟悉程度各不相同的人使用。如果你还没听说过这种趋势（这也是最近才兴起的），Claude 的强大能力正激励着水管工打开终端，也让父母和祖父母开始搜索“如何安装 npm”。另一方面，大多数用户的计算机知识可能都比较丰富。

因此，请留意上下文线索，判断该如何措辞！一般来说，可以参考以下建议：

• “评估”和“基准测试”这两个词比较专业，但可以使用
• 对于“JSON”和“断言”，除非用户有明显迹象表明他们了解这些概念，否则使用时应加以解释

如果拿不准，简单解释一下术语也没问题；如果不确定用户是否理解，可以用简短的定义说明术语。

---

创建技能

明确意图

首先要了解用户的意图。当前对话中可能已经包含了用户希望固化为技能的工作流（例如，他们说“把这个变成一个技能”）。如果是这样，先从对话历史中提取相关信息——使用了哪些工具、步骤顺序、用户做过哪些更正、观察到哪些输入/输出格式。用户可能需要补充缺失信息，并应在进入下一步前确认。

1. 这个技能应让 AI Agent 能够做什么？
2. 什么时候应触发这个技能？（哪些用户表达或上下文）
3. 预期的输出格式是什么？
4. 是否应设置测试用例来验证技能是否有效？对于输出可客观验证的技能（文件转换、数据提取、代码生成、固定工作流步骤），测试用例很有帮助。对于输出较为主观的技能（写作风格、艺术创作），通常不需要测试用例。根据技能类型建议合适的默认方案，但由用户决定。
5. 这个技能面向哪种工具？（Claude Code、Cursor，还是两者都支持？）

目标平台

Claude Code 和 Cursor 的 SKILL.md 格式完全相同，包括相同的 YAML frontmatter 和目录结构。主要区别：

• Claude Code 从 .claude/skills/ 发现技能
• Cursor 从 .cursor/skills/、.agents/skills/、~/.cursor/skills/ 和 .claude/skills/（旧版）发现技能
• 跨平台：将技能放在 .agents/skills/ 中，即可让这两个工具都发现它们
• 仅限 Cursor 的字段：在 frontmatter 中设置 disable-model-invocation: true，可使技能只能通过 /skill-name 调用（不会自动触发）

为两个平台创建技能时，避免在技能正文中引用特定工具的功能（例如 Claude 的 Skill 工具与 Cursor 的 /skill-name 调用方式）。

访谈和调研

主动询问边界情况、输入／输出格式、示例文件、成功标准和依赖项。理清这些内容后，再编写测试提示词。

检查可用的 MCP；如果有适合调研的 MCP（用于搜索文档、查找类似技能、了解最佳实践），且可使用子 Agent，则并行调研；否则直接进行调研。提前准备好相关背景信息，减轻用户负担。

编写 SKILL.md

根据用户访谈，填写以下部分：

• name：技能标识符
• description：何时触发以及技能的作用。这是主要的触发机制——同时说明技能的作用和具体适用场景。所有“何时使用”的信息都应放在这里，而不是正文中。注意：目前 AI Agent（Claude 和 Cursor）都倾向于“触发不足”——在技能有用时也不使用。为解决这个问题，请让技能描述更具主动性。例如，与其写“如何构建一个简单、快速的仪表板来展示 Anthropic 的内部数据”，不如写“如何构建一个简单、快速的仪表板来展示 Anthropic 的内部数据。每当用户提到仪表板、数据可视化、内部指标，或想展示任何公司数据时，都务必使用此技能，即使他们没有明确提出要制作‘仪表板’。”
• compatibility：所需工具、依赖项（可选，较少需要）
• 技能的其余部分 :)

技能编写指南

技能的组成

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)

渐进式披露

技能采用三级加载系统：

1. 元数据（name + description）——始终在上下文中（约 100 个单词）
2. SKILL.md 正文——技能触发时加载到上下文中（理想情况下少于 500 行）
3. 打包的资源——按需加载（数量不限，脚本可在不加载的情况下执行）

这些字数仅为估算，如有需要，可以适当增加。

关键模式：

• 将 SKILL.md 控制在 500 行以内；如果接近此上限，请增加一层层级结构，并明确指出模型接下来应查看哪些内容。
• 在 SKILL.md 中清楚地引用文件，并说明何时阅读这些文件
• 对于较大的参考文件（超过 300 行），请包含目录

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

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

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

不令人意外原则

这无需多言，但技能不得包含恶意软件、漏洞利用代码或任何可能危害系统安全的内容。如果技能内容如实描述，用户不应对其意图感到意外。不要接受创建误导性技能，或旨在协助未经授权的访问、数据窃取或其他恶意活动的请求。不过，像“扮演某某角色”这样的内容是可以的。

写作模式

指令优先使用祈使句。

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

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

写作风格

尽量向模型解释事物为何重要，而不是生硬地堆砌必须遵守的要求。运用心智理论，尽量让技能具有通用性，而不是局限于非常具体的示例。先写一份草稿，再以全新的视角审阅并改进。

测试用例

写完技能草稿后，构思 2-3 个真实的测试提示词，也就是实际用户可能会说的话。与用户分享这些提示词：“我想试试几个测试用例。你觉得这些合适吗？还是想再补充几个？”（不必使用这句原话。）然后运行这些测试。

将测试用例保存到 evals/evals.json。暂时不要编写断言——运行进行期间，你会在下一步草拟断言。

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

完整的架构（包括稍后添加的 assertions 字段）请参见 references/schemas.md。

运行和评估测试用例

本节是一个连续的流程——不要中途停止。不要使用 /skill-test 或任何其他测试技能。

将结果放在 <skill-name>-workspace/ 中，使其与技能目录处于同一层级。在工作区内，按迭代整理结果（iteration-1/、iteration-2/ 等），并在每次迭代中为每个测试用例建立一个目录（eval-0/、eval-1/ 等）。不要预先创建所有目录——按需逐步创建。

步骤 1：在同一轮中启动所有运行（使用技能和基准运行）

对每个测试用例，启动两次运行——一次使用技能，一次不使用技能。

在 Claude Code 中（使用子代理）：在同一轮中启动所有运行，让它们大致同时完成。不要先启动使用技能的运行，之后再启动基准运行。

在 Cursor 中（没有子代理）：按顺序运行测试用例——先阅读技能，再针对每个测试提示词遵循其说明。这种方式不够严谨，但人工审查环节可以弥补这一点。

使用技能的运行：

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

基准运行（使用相同的提示词，但基准取决于上下文）：

• 创建新技能：完全不使用技能。使用相同提示词，不提供技能路径，并将结果保存到 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": "The user's task 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，而不是自定义脚本

程序化检查（文件是否存在、行数、字符串匹配）很有用，可以作为补充，但它们只能检查结构是否符合要求。评分 Agent 能发现脚本无法发现的问题：内容质量、主张核实，以及会造成虚假信心的薄弱断言。技能可以在正确的位置生成所有文件，但内容仍可能非常糟糕——评分 Agent 就是用来发现这一点的。每次运行的 grading.json 文件都生成之前，切勿生成查看器或基准测试。

所有运行完成后：

1. 为每次运行评分 — 启动评分子 Agent（或直接评分），让它读取 agents/grader.md 并根据输出评估每项断言。将结果保存到每个运行目录中的 grading.json。grading.json 中的 expectations 数组必须使用 text、passed 和 evidence 字段（不能使用 name/met/details 等其他字段）——查看器依赖这些确切的字段名。可以将程序化检查作为评分 Agent 的补充（脚本更快，也便于重复执行文件是否存在或行数等检查），但它们不能取代评分 Agent——始终先运行评分 Agent，进行定性评估。

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 中的“分析基准测试结果”部分，了解需要关注的内容，例如无论是否使用技能都会通过的断言（区分度不足）、方差较大的评估（可能不稳定），以及时间和 token 之间的权衡。

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

   **无头环境：**如果 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：

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

反馈为空表示用户觉得结果没问题。改进时重点关注用户提出具体意见的测试用例。

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

kill $VIEWER_PID 2>/dev/null

---

改进技能

这是整个循环的核心。你已经运行了测试用例，用户也已查看结果，现在你需要根据他们的反馈改进技能。

如何思考改进

1. 从反馈中总结规律。 这里正在发生的事情，从大局来看，就是要创建一种可反复使用数百万次（也许真的会有那么多，甚至更多）的技能，用于许多不同的提示词。你和用户在这里反复迭代少数几个示例，只是为了加快进度。用户对这些示例了如指掌，也能快速评估新的输出。但如果你和用户共同开发的技能只适用于这些示例，那它就毫无用处。与其做琐碎、过度拟合的改动，或加上令人窒息的严格要求，如果某个问题一直难以解决，不妨尝试换一种比喻，或推荐不同的工作模式。尝试的成本相对较低，说不定就能找到绝佳方案。

2. 让提示词保持精简。 删除没有实际作用的内容。确保阅读完整对话记录，而不只是最终输出——如果技能似乎让模型浪费大量时间做无用功，可以尝试删掉导致这种情况的部分，看看效果如何。

3. 解释原因。 尽力说明要求模型做每件事背后的原因。如今的大模型很聪明。它们有很强的心智理论能力，只要配备合适的引导机制，就能超越机械执行指令，真正把事情做好。即使用户的反馈简短或带有不满，也要努力理解任务本身、用户为什么这样写，以及他们实际写了什么，然后把这种理解融入指令中。如果你发现自己在用全大写的 ALWAYS 或 NEVER，或采用非常僵化的结构，这就是一个警示信号——如果可能，换一种表述方式，解释理由，让模型理解你提出该要求的重要性。这种做法更人性化、更有力，也更有效。

4. 留意测试用例之间重复的工作。 阅读测试运行的对话记录，看看子 Agent 是否都独立编写了类似的辅助脚本，或采取了相同的多步骤方法。如果 3 个测试用例都导致子 Agent 编写了 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。基本思路是：将两个输出交给一个独立 Agent，但不告知它们分别对应哪个版本，让它判断质量。然后分析胜出版本的原因。

这是可选流程，需要使用子 Agent，大多数用户都用不到。人工评审循环通常就足够了。

---

描述优化

SKILL.md frontmatter 中的 description 字段是决定 Claude 是否调用某项技能的主要机制。创建或改进技能后，可以提出优化 description，以提高触发准确率。

第 1 步：生成触发评估查询

创建 20 条评估查询，混合应触发和不应触发的查询。保存为 JSON：

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

查询必须真实可信，是 Claude Code 或 Cursor 用户确实会输入的内容。不要写抽象请求，而要写具体、明确且细节充分的请求。例如，包含文件路径、用户工作的个人背景、列名和值、公司名称、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__ → 评估项目的 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、添加/删除条目，然后点击“Export Eval Set”
5. 文件会下载到 ~/Downloads/eval_set.json——如果有多个版本（例如 eval_set (1).json），请检查 Downloads 文件夹并找到最新版本

这一步很重要——糟糕的评估查询会导致糟糕的描述。

步骤 3：运行优化循环

API 密钥前置条件： 运行前确保凭据已加载。按照上文 API Credentials 部分的步骤操作——检查环境变量、加载 .env，或在缺少文件时请用户创建一个。

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

将评估集保存到工作区，然后在后台运行：

source .env && python -m scripts.run_loop \
  --eval-set <path-to-trigger-eval.json> \
  --skill-path <path-to-skill> \
  --model ${SKILL_MODEL} \
  --platform <claude|cursor> \
  --max-iterations 5 \
  --verbose

使用 .env 中的 $SKILL_MODEL。如果未设置，则回退到系统提示词中的模型 ID（即当前会话所用的模型），这样触发测试才能匹配用户实际体验。对于 Cursor 技能，设置 --platform cursor（使用 LLM 模拟，而不是 claude -p CLI）。

运行期间，定期查看输出末尾，向用户更新当前迭代次数和分数情况。

此操作会自动处理完整的优化循环。它会将评估集拆分为 60% 训练集和 40% 留出测试集，评估当前描述（每个查询运行 3 次，以获得可靠的触发率），然后调用 Claude 并启用扩展思考，根据失败情况提出改进方案。它会在训练集和测试集上重新评估每个新描述，最多迭代 5 次。完成后，它会在浏览器中打开一份 HTML 报告，展示各轮迭代的结果，并返回包含 best_description 的 JSON——根据测试集分数而非训练集分数进行选择，以避免过拟合。

技能触发机制

了解触发机制有助于设计更好的评估查询。技能会以名称和描述的形式出现在 Agent 的 available_skills 列表中，Agent 会根据描述决定是否查阅某项技能。需要注意的是，AI Agent 只会在无法轻松自行处理任务时查阅技能——像“读取此 PDF”这样简单、只需一步的查询，即使描述完全匹配，也可能不会触发技能，因为 Agent 可以直接使用基础工具处理。描述匹配时，复杂、多步骤或专业化的查询则能可靠地触发技能。

这意味着评估查询应该足够实质，让 Claude 确实能从查阅技能中受益。像“读取文件 X”这样的简单查询不是好的测试用例——无论描述质量如何，它们都不会触发技能。

步骤 4：应用结果

从 JSON 输出中取出 best_description，并更新技能 SKILL.md 的 frontmatter。向用户展示修改前后的内容，并报告分数。

---

打包并展示（仅当 present_files 工具可用时）

检查你是否可以使用 present_files 工具。如果不能，请跳过此步骤。如果可以，请打包技能并向用户展示 .skill 文件：

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

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

Cursor 专用说明

在 Cursor 中运行时：

• 核心工作流相同：起草、测试、审查、改进、重复。
• Cursor 没有子 Agent。请按顺序运行测试用例——先阅读技能的 SKILL.md，然后按照其中的说明，逐个自行完成测试提示词。
• 所有 Python 脚本（run_eval、run_loop、improve_description、package_skill）都使用 --platform cursor。
• 描述优化使用 LLM 模拟，而非 CLI 测试。模拟会询问模型：“根据此查询，你会调用这项技能吗？”——这种方式可用于比较不同描述的相对效果，但无法完美代表 Cursor 的实际运行行为。
• Cursor 支持 disable-model-invocation: true frontmatter 字段——对于只能通过 /skill-name 调用、绝不应由 Agent 自动触发的技能，请设置此字段。
• 盲测比较需要子 Agent——在 Cursor 中跳过。
• 打包方式完全相同。将生成的技能文件夹放入 .cursor/skills/（跨平台使用 .agents/skills/）。
• 生成 eval 查看器时，如果你的 Cursor 环境中无法使用 webbrowser.open()，请使用 --static <output_path>。

---

参考文件

agents/ 目录包含专用子 Agent 的说明。需要启动相关子 Agent 时，请阅读这些说明。

• agents/grader.md — 如何根据输出评估断言
• agents/comparator.md — 如何对两个输出进行盲测 A/B 比较
• agents/analyzer.md — 如何分析某个版本胜出的原因

references/ 目录包含其他文档：

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

---

再强调一次核心循环：

• 弄清技能的用途
• 起草或编辑技能
• 让能够访问该技能的 Agent 根据测试提示词运行
• 与用户一起评估输出：
  • 创建 benchmark.json 并运行 eval-viewer/generate_review.py，帮助用户审查输出
  • 运行量化评估
• 重复上述过程，直到你和用户都满意
• 打包最终技能并交付给用户。

如果你有 TodoList，请添加这些步骤，确保不会忘记。

祝你好运！