---
name: meta-skill-writer
version: "1.3.0"
description: "帮我写个 skill。"
---

# Meta Skill Writer — 教你写 Skill 的 Skill

当用户提出「帮我写个 skill」时，按以下方法论创建。

## 核心原则

### 1. 渐进式加载优先
- **description**：只放触发条件，不放教程。让 Agent 一眼判断"这个场景该不该用我"
- **SKILL.md**：放操作流程和规则。描述工作步骤，不是原理说明
- **references/**：放长文档、API 说明、示例。只在执行中需要时才读
- **scripts/**：放确定性的机械操作。不要用脚本做"AI 文本处理"，要用脚本做"格式校验/API调用/文件操作"
- 不需要一开始就把所有内容塞进 prompt

### 2. 角色定位清晰
- 一个 skill 只做**一类任务**
- 如果发现 SKILL.md 里在写"如果是场景A就…如果是场景B就…"，说明该拆成两个 skill 了

### 3. 可测试
- 每个 skill 都应该能用 `openclaw skills check` 验证依赖
- 关键的脚本路径应该能在命令行独立测试

## 工作流

### Step 1：需求分析

和用户确认三个问题：

1. **用户说什么话时应该触发这个 skill？** → 这就是 future description
2. **这个 skill 处理完交付什么？** → 确定输出（文件？消息？数据？）
3. **它的上游输入和下游依赖是什么？** → API？本地工具？用户手动提供？

### Step 2：结构设计

按以下规则决定目录结构：

**最小集（大部分场景够用）：**
```
skill-name/
├── SKILL.md          # 必需。核心说明书
├── scripts/          # 可选。确定性脚本
├── references/       # 可选。长文档/参考
├── examples/         # 可选。输入输出样例
└── evals/            # 可选。最小评测集
```

**什么时候加 scripts/：**
- 有重复的格式化/校验/转换操作
- 有外部 API 调用
- 操作顺序固定、参数明确、不依赖 AI 判断

**什么时候加 references/：**
- API 文档太长，放 SKILL.md 里会冲淡流程
- 有 checklist、示例、模板需要按需读取
- 有业务背景知识但并非每次都需要

**什么时候加 examples/：**
- 输出格式复杂，Agent 容易跑偏
- 同一个任务有多种正确结果的风格，需要有参考对照
- 边界情况（如空输入、错误输入）的预期输出不好描述
- 好的做法：放 1-3 个好例子 + 1 个坏例子，标明为什么好/坏

**什么时候加 evals/：**
- skill 有核心路径不能倒退（改了某处不能把原本会做的做坏）
- 有多个脚本需要联动验证
- 需要定期回归检查的场景
- 最小评测集：5-10 个输入 + 预期输出，每次迭代后跑一遍

**什么时候不该加：**
- 不需要把"用 Python 的话要怎么装依赖"写成脚本（模型已经知道）
- 不需要把明显的常识性知识塞进 references
- examples/ 和 evals/ 不是越大越好——精选 3-5 个高质量样例胜过 20 个凑数的

### Step 3：写 SKILL.md

使用 `references/skill-template.md` 作为起点，填充以下内容：

**frontmatter 必须包含：**
```yaml
---
name: skill-name           # 简短，kebab-case
version: "1.0.0"           # 语义化版本
description: "一句话说明"   # 关键！Agent 靠这个判断是否触发
---
```

**description 写作原则：**
- **直接用用户会说的话** — 不用加"当用户说…时"这种包装。用户会说"帮我评估一下这个skill"，那 description 就写「帮我评估一下这个 skill」，一字不改
- 只写触发条件，不写功能描述
- 不写步骤细节（那些放正文）
- 中英文均可，但要一致

**对比案例（multi-agent-skill-evaluator 的真实迭代）：**

| 版本 | description | 问题 |
|------|------------|------|
| ❌ v1.2 | Multi-agent独立技能评估。对任意skill，通过3个隔离的子agent分别打分+评语，最后汇总报告 | 描述功能，不是触发条件 |
| ❌ v1.3 | 当你想评估某个 skill 能不能胜任它的工作... | 好了点，但还有包装 |
| ✅ v1.4 | **帮我评估一下这个 skill** | 用户会说的话，一字不改 |

**正文结构：**
```
# Skill 名称 — 一句话用途
(如果超出 2 行，说明 skill 范围太大)

## 首次设置（如果没有就是空）
## 工作流（核心步骤，从触发到交付）
## 输出格式（如果有）
## 注意事项
```

**正文写作原则：**
- 写操作步骤，不是写原理
- 每步说明"做什么"和"为什么"，但不写"怎么实现"（模型知道怎么实现）
- 边界条件写清楚："什么情况下停下来问用户"、"什么情况下继续"
- 错误处理写清楚："失败了怎么办"、"预期时长"

### Step 4：创建脚本（如果需要）

脚本的原则：
- **可独立测试**：`bash script.sh "input"` 应该能跑通
- **参数化**：不要硬编码路径，用参数或环境变量
- **有错误处理**：检查输入、检查依赖、检查返回值
- **有回退策略**：主方案失败时尝试次方案

### Step 5：自检清单

完成前逐项自查：

- [ ] description 是否直接用用户会说的话？
- [ ] SKILL.md 把"怎么做"写清楚了吗？AI 按步骤执行会不会卡住？
- [ ] 有没有把常识性知识写进 skill（模型不需要教）？
- [ ] 是否有测试过关键脚本路径？
- [ ] 输出格式是否明确？
- [ ] 失败场景是否说明？
- [ ] 依赖是否在 metadata 中声明？
- [ ] examples/ 和 evals/ 如果加了，内容是否精选而非凑数？

### Step 6：可选——让 skill-evaluator 评估

创建完成后，可以调用 `multi-agent-skill-evaluator` 对新建的 skill 进行质量评估，获取改进建议。

## 常见反模式

| 反模式 | 说明 | 正确做法 |
|--------|------|---------|
| description 写成长文 | 触发条件模糊 | **直接用用户会说的话** |
| SKILL.md 里塞 API 文档 | 冲淡操作流程 | 放 references/ |
| 一个 skill 做两件事 | 职责不清 | 拆成两个 |
| 用脚本做 AI 判断 | 脚本不应该依赖 AI | 脚本只做确定性操作 |
| 缺少错误处理 | 失败时用户不知道怎么办 | 写明"如果 X 失败，告诉用户 Y" |
| 硬编码路径/凭据 | 不可移植 | 用参数/环境变量 |