Skill

如何创建 Skill

把可重复的经验变成一个小而清楚的包，让 Agent 能稳定发现、激活和执行。

从真实工作开始

不要从一个通用提示词开始。先找一个已经有人成功完成过的任务，再把当时的决策、检查项、文件和输出格式抽出来。

真实任务记录真实步骤，再删掉只适用于那一次的细节。

现有材料把 runbook、SOP、模板、评审记录、脚本和内部文档当素材。

来源笔记示例

把混乱的真实笔记整理成可复用流程，不要直接把脏笔记原封不动发布出去。

真实任务笔记：
- 用户贴了一串 PR 列表。
- 去掉内部重构项。
- 把 SSO 放进 Highlights。
- 时区导出 bug 放进 Fixes。
- 询问 billing worker 重构是否该提。
- 最终格式包括 Highlights、Fixes、Docs、Open questions。

只选一个任务

Skill 需要清晰的激活边界。如果它处理的任务太杂，Agent 要么过度触发，要么在真正需要时不去触发。

好范围 “为数据库 schema 变更生成迁移风险评审”比“帮忙处理数据库”更容易使用和评估。

写操作性说明

激活说明

明确它适用于什么样的用户说法和情境，也要说清楚哪些时候不该激活。

流程

把工作流写成 Agent 能执行的动作，而不是抽象建议。

默认值

给出默认假设，别让 Agent 什么小选项都回头问用户。

输出模板

只要最终形状重要，就把报告、清单、表格或文件格式写死。

改前改后

弱指令：
"写好发布说明。"

操作性指令：
"把用户可见变更分成 Highlights、Fixes 和 Docs。
除非用户要工程说明，否则排除纯内部重构。
如果某项变更含糊，就放进 Open questions，而不要猜。"

打包辅助资源

让 SKILL.md 保持足够短，便于加载。把详细参考、长示例、模板或可复用脚本放进独立文件。

release-notes/
├── SKILL.md
├── assets/
│   └── release-note-template.md
├── references/
│   └── product-taxonomy.md
└── scripts/
    └── collect-changelog.js

最小可发布的 SKILL.md

---
name: release-notes
description: 根据合并的 PR、提交记录或 changelog 撰写面向客户的发布说明。
---

# 发布说明

当用户要你写发布说明、变更日志文案，或者面向客户的已发布变更总结时使用这个 Skill。
不要用于事故报告、迭代计划或内部工程总结。

## 工作流
1. 提取用户可见变更。
2. 分成 Highlights、Fixes、Docs 和 Open questions。
3. 除非用户要求，否则删除纯内部工作。
4. 用面向客户的语言写简洁要点。
5. 遇到含糊项就提问，不要自己发明产品影响。

写测试提示词

Skill 不是把文件写出来就完事了。要用应该触发和不该触发的请求来测试它。

应触发：
- 把这些合并的 PR 写成客户发布说明。
- 为本周发布内容写 changelog 文案。
- 写发布说明，并标出不清楚的项。

不应触发：
- 解释什么是语义化版本。
- 总结这份事故报告。
- 创建一个迭代计划清单。

根据失败不断打磨

用真实例子跑 Skill，看 Agent 卡在哪里，再改说明。好的 Skill 往往不是一次写出来的，而是经过几轮小修补磨出来的。

在 Agent 容易误判的地方加坑点。
把长背景搬到 references，并按条件加载。
如果 Skill 触发太广或太窄，就收紧描述。
只有当示例真的改变了行为时，再把它加进去。