skill-creator

name	skill-creator
description	帮助用户创建新的 Agent Skill，包括需求分析、SKILL.md 编写和结构设计。当用户想要从零创建一个 Skill、改进现有 Skill 的结构或内容时使用。

Skill Creator

一个帮助你创建高质量 Agent Skill 的工具。

创建 Skill 的核心流程：

1. 明确 Skill 的目标和触发场景
2. 收集需求细节和边界条件
3. 编写 SKILL.md 初稿
4. 创建测试用例验证效果
5. 根据反馈迭代改进

你的职责是判断用户当前处于哪个阶段，然后帮助他们推进。如果用户已经有了初稿，可以直接进入改进阶段。

---

创建 Skill

Capture Intent（捕获意图）

首先理解用户的意图。当前对话中可能已经包含了用户想要封装的工作流（比如他们说"把这个流程变成一个 Skill"）。如果是这样，先从对话历史中提取信息——使用了哪些工具、步骤顺序、用户做了哪些修正、观察到的输入输出格式。用户可能需要补充细节，确认后再进入下一步。

1. 这个 Skill 要让 Agent 完成什么任务？
2. 什么情况下应该触发这个 Skill？（哪些用户提问/场景）
3. 期望的输出格式是什么？
4. 是否需要设置测试用例来验证 Skill 的效果？有客观可验证输出的 Skill（文件转换、数据提取、代码生成、固定流程步骤）适合测试用例；主观输出的 Skill（写作风格、设计）通常不需要。根据 Skill 类型建议合适的默认方案，但让用户决定。

Interview and Research（访谈与调研）

主动询问边界情况、输入输出格式、示例文件、成功标准和依赖关系。在搞清楚这些之前，不要急着写测试用例。

如果有可用的工具（搜索文档、查找类似 Skill、查阅最佳实践），先做调研，带着充分的上下文来减轻用户的负担。

Write the SKILL.md（编写 SKILL.md）

基于用户访谈，填写以下组成部分：

• name：Skill 标识符
• description：触发条件和功能描述。这是主要的触发机制——既要说明 Skill 做什么，也要说明何时使用。所有"何时使用"的信息都放在这里，而不是放在正文中。注意：为了确保触发率，description 应该适度"积极"。例如，与其写"构建数据可视化面板"，不如写"构建数据可视化面板。当用户提到仪表盘、数据展示、指标监控，或想要展示任何类型的数据时都应使用此 Skill，即使他们没有明确要求'面板'。"
• compatibility：所需工具、依赖（可选，很少需要）
• 正文内容

---

Skill 编写指南

Skill 的结构

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

Progressive Disclosure（渐进式披露）

Skill 使用三级加载系统：

1. 元数据（name + description）- 始终在上下文中（约 100 词）
2. SKILL.md 正文 - Skill 触发时加载（理想情况 <500 行）
3. 捆绑资源 - 按需加载（不限大小，脚本可以在不加载的情况下执行）

这些字数是近似值，如果需要可以更长。

关键模式：

• 保持 SKILL.md 在 500 行以内；如果接近这个限制，添加层级结构并指明下一步应该阅读哪些文件
• 在 SKILL.md 中清晰引用文件，并说明何时应该读取它们
• 对于大型参考文件（>300 行），包含目录

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

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

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

安全原则

Skill 不得包含恶意软件、利用代码或任何可能危害系统安全的内容。Skill 的内容在被描述时不应让用户感到意外。不要创建误导性的 Skill 或旨在促进未授权访问的 Skill。

编写模式

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

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

## 报告结构
始终使用这个模板：
# [标题]
## 摘要
## 关键发现
## 建议

示例模式——包含示例很有用：

## Commit 消息格式
**示例 1：**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication

编写风格

尽量向模型解释"为什么"事情很重要，而不是堆砌强硬的 MUST/NEVER。利用心智理论，让 Skill 通用化而非局限于特定示例。先写初稿，然后用新鲜的眼光审视并改进。

---

迭代改进

如何思考改进方向

1. 从反馈中泛化。 我们创建的 Skill 将被在各种不同的场景中使用。不要针对测试用例过度拟合，而是理解用户反馈背后的通用模式。与其添加僵硬的限制条件，不如尝试不同的表达方式或工作模式。

2. 保持指令精简。 移除没有发挥作用的内容。如果 Agent 在执行 Skill 时浪费时间在无用的步骤上，考虑删除导致这种行为的指令部分。

3. 解释为什么。 尽量解释每条指令背后的原因。当前的大模型很聪明，给出好的上下文后能超越机械执行。如果你发现自己在写 ALWAYS 或 NEVER（全大写），这是一个信号——重新表述，解释推理过程，让模型理解为什么这很重要。

4. 寻找重复工作。 如果多个测试用例中 Agent 都独立编写了类似的辅助脚本，这强烈暗示 Skill 应该捆绑该脚本。写一次，放在 scripts/ 中，让 Skill 指引 Agent 使用它。

---

测试用例

编写 Skill 初稿后，构思 2-3 个真实的测试提示——真正的用户会实际说的话。与用户分享："这是我想测试的几个用例，看起来合理吗？需要补充吗？"

好的测试用例是具体的、有细节的，而不是抽象的请求。

不好："格式化这个数据", "从 PDF 中提取文本"

好："我老板刚发了一个 xlsx 文件给我（在我的下载目录里，叫'Q4销售数据_最终版v2.xlsx'），她让我加一列利润率百分比。营收在 C 列，成本在 D 列。"