By name: skill-creator description: 帮助用户创建新的 Agent Skill，包括需求分析、SKILL.md 编写和结构设计。当用户想要从零创建一个 Skill、改进现有 Skill 的结构或内容时使用。
Skill Creator
一个帮助你创建高质量 Agent Skill 的工具。
创建 Skill 的核心流程：
- 明确 Skill 的目标和触发场景
- 收集需求细节和边界条件
- 编写 SKILL.md 初稿
- 创建测试用例验证效果
- 根据反馈迭代改进
你的职责是判断用户当前处于哪个阶段，然后帮助他们推进。如果用户已经有了初稿，可以直接进入改进阶段。
创建 Skill
Capture Intent（捕获意图）
首先理解用户的意图。当前对话中可能已经包含了用户想要封装的工作流（比如他们说"把这个流程变成一个 Skill"）。如果是这样，先从对话历史中提取信息——使用了哪些工具、步骤顺序、用户做了哪些修正、观察到的输入输出格式。用户可能需要补充细节，确认后再进入下一步。
- 这个 Skill 要让 Agent 完成什么任务？
- 什么情况下应该触发这个 Skill？（哪些用户提问/场景）
- 期望的输出格式是什么？
- 是否需要设置测试用例来验证 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 使用三级加载系统：
- 元数据（name + description）- 始终在上下文中（约 100 词）
- SKILL.md 正文 - Skill 触发时加载（理想情况 <500 行）
- 捆绑资源 - 按需加载（不限大小，脚本可以在不加载的情况下执行）
这些字数是近似值，如果需要可以更长。
关键模式：
- 保持 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 通用化而非局限于特定示例。先写初稿，然后用新鲜的眼光审视并改进。
迭代改进
如何思考改进方向
从反馈中泛化。 我们创建的 Skill 将被在各种不同的场景中使用。不要针对测试用例过度拟合，而是理解用户反馈背后的通用模式。与其添加僵硬的限制条件，不如尝试不同的表达方式或工作模式。
保持指令精简。 移除没有发挥作用的内容。如果 Agent 在执行 Skill 时浪费时间在无用的步骤上，考虑删除导致这种行为的指令部分。
解释为什么。 尽量解释每条指令背后的原因。当前的大模型很聪明，给出好的上下文后能超越机械执行。如果你发现自己在写 ALWAYS 或 NEVER（全大写），这是一个信号——重新表述，解释推理过程，让模型理解为什么这很重要。
寻找重复工作。 如果多个测试用例中 Agent 都独立编写了类似的辅助脚本，这强烈暗示 Skill 应该捆绑该脚本。写一次，放在
scripts/中，让 Skill 指引 Agent 使用它。
测试用例
编写 Skill 初稿后，构思 2-3 个真实的测试提示——真正的用户会实际说的话。与用户分享："这是我想测试的几个用例，看起来合理吗？需要补充吗？"
好的测试用例是具体的、有细节的，而不是抽象的请求。
不好："格式化这个数据", "从 PDF 中提取文本"
好："我老板刚发了一个 xlsx 文件给我（在我的下载目录里，叫'Q4销售数据_最终版v2.xlsx'），她让我加一列利润率百分比。营收在 C 列，成本在 D 列。"