# Skill Creator

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

- Skill: `alibabaclouddocs/skill-creator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add alibabaclouddocs/skill-creator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alibabaclouddocs/skill-creator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: alibabaclouddocs (https://skillmd.com/u/alibabaclouddocs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alibabaclouddocs/skill-creator

---


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

### 编写模式

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

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

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

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

```markdown
## 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 列。"`