skill-creator

Skill Creator

用于创建新技能并持续改进技能的技能。

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

• 确定技能应该实现什么功能，以及大致如何实现
• 编写技能初稿（SKILL.md）
• 使用几个贴近实际的测试提示词试用该技能
• 评估结果：既进行定性评估（输出看起来是否正确？），也尽可能使用简单、可验证的断言进行评估
• 根据观察到的情况改进技能
• 重复以上步骤，直到满意为止
• 优化描述，以便准确触发技能

使用此技能时，你的任务是判断用户处于流程的哪个阶段，并帮助他们推进。如果他们说“我想为 X 创建一个技能”，就帮助他们明确需求、编写初稿、尝试几个贴近实际的提示词，并逐步迭代。如果他们已经有初稿，就直接开始测试和迭代。

如果用户只是说“随意和我聊聊，不要正式评估”，就照做。

与用户沟通

Skill-creator 可能会被编码术语熟悉程度各不相同的人使用。请留意上下文线索：

• “评估”／“基准测试”——大致可以直接使用
• “JSON”／“断言”——除非用户表现出熟悉，否则请解释

如有疑问，可以简单解释术语。

捕捉意图

首先了解用户想要什么。当前对话中可能已经包含了需要捕捉的工作流（例如，他们说“把这个变成一个技能”）。如果是这样，请先从对话历史中提取相关信息——使用过的工具、步骤顺序、所做的修正，以及观察到的输入／输出格式。用户可以补充缺失的信息并确认。

询问：

1. 这个技能应该让模型能够做什么？
2. 什么时候应该触发？（用户会说什么，或处于什么情境）
3. 预期的输出格式是什么？
4. 是否应该设置测试用例来验证技能是否有效？对于输出客观可验证的技能（文件转换、数据提取、代码生成、固定工作流步骤），测试用例会很有帮助。对于输出较为主观的技能（写作风格、艺术创作），通常不需要。建议合适的默认方案，但由用户决定。

访谈与研究

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

如果平台支持并行子任务，请并行开展研究（搜索文档、查找类似技能、检查最佳实践）。

编写 SKILL.md

根据访谈结果，填写以下内容：

• name — 技能标识符（必须与目录名称一致；使用小写字母、数字和单个连字符，正则表达式为 ^[a-z0-9]+(-[a-z0-9]+)*$）。
• description — 何时触发以及技能的功能。这是主要的触发机制。同时说明技能的功能，以及使用该技能的具体情境。所有“何时使用”的信息都应放在这里，而不是正文中。技能往往不容易触发，因此描述应稍微积极一些。例如，与其写 “构建一个快速仪表板”，不如写 “构建一个快速仪表板。每当用户提到仪表板、数据可视化、内部指标，或想要展示任何类型的公司数据时，都要使用此技能，即使他们没有明确提出要‘仪表板’。”
• license（可选）— 技能采用的许可证。

然后编写正文。

技能的组成

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. 元数据（名称 + 描述）——始终处于上下文中，约 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

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

避免意外原则

技能不得包含恶意软件、漏洞利用代码，或任何可能危及系统安全的内容。技能内容不应超出用户根据其描述所预期的范围。不要创建误导性技能，也不要创建旨在协助未授权访问、数据外泄或其他恶意活动的技能。角色扮演类技能没有问题。

写作风格

• 在指令中使用祈使句（“执行 X”“运行 Y”）。
• 解释指令背后的原因。 如今的模型很聪明，遵循推理比遵循僵硬规则更有效。如果你发现自己在写全大写的 MUST 和 NEVER，这就是一个警示信号。请换一种方式解释。
• 让指令通用且可复用，不要局限于特定测试示例。

定义输出格式——使用清晰的模板：

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

示例模式——简短、具体的示例很有帮助：

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

测试用例

起草完成后，想出 2–3 条真实的测试提示词——也就是现实用户可能会说的话。与用户分享：“这里有几个我想尝试的测试用例。你觉得合适吗？还是想再添加一些？”

用每条提示词测试技能。阅读对话记录（不只是最终输出），看看技能是否导致模型在无益的步骤上浪费精力。

迭代

• 从反馈中归纳。 技能会在许多提示词中反复使用。避免过度拟合测试用例。如果某个问题难以解决，试试换一种比喻或模式，而不是添加更多僵硬的 MUST。
• 精简提示词。 删除没有实际作用的指令。
• 解释原因。 模型遵循推理比死记硬背更有效。
• 留意测试用例之间的重复工作。 如果多次运行都各自编写了相同的辅助脚本，这说明可以将其打包到 scripts/ 下，并告知技能使用它。

改进技能后，重新运行测试提示词，检查问题是否已解决，同时确认先前的行为没有退化。

描述优化（进阶）

description 字段是决定模型是否调用技能的主要机制。要优化它：

1. 生成约 20 条触发评估查询——既包括应该触发的，也包括不应该触发的。不应该触发的查询应与触发条件相近，而不是明显无关。
2. 请用户审核评估集。
3. 迭代优化描述，并使用训练查询和留出测试查询测试每个版本。为避免过度拟合，请选择在留出集上表现最佳的描述，而不是在训练集上表现最佳的版本。

备注

这是对 anthropics/skills/skills/skill-creator 的修改版移植。上游版本附带打包脚本和 HTML 评估查看器（scripts/aggregate_benchmark.py、eval-viewer/generate_review.py 等），此处未包含。经审核的上游快照固定在 UPSTREAMS.json 中。