五分钟热身：把一段提示变成 /命令

2.1 最小的技能只有一个文件

别被”技能”这个词吓到。最小的技能就是一个 SKILL.md 文件，里面一段 frontmatter、一段正文，没了。

我们要固化的提示，是团队每次发版都要口述的那段：“把这次的改动整理成发布说明，按’新增/修复/破坏性变更’分三类，每条一句话，面向使用者而不是开发者。”

先建目录。放在个人目录 ~/.claude/skills/ 下，这样你所有项目都能用：

mkdir -p ~/.claude/skills/release-notes

然后写 ~/.claude/skills/release-notes/SKILL.md：

---
description: 把改动整理成面向使用者的发布说明。当用户要写发布说明、release notes 或 changelog 时使用。
---

把提供给你的改动整理成一份发布说明。

规则：
- 按"新增 / 修复 / 破坏性变更"分三类，某类为空就省略该类
- 每条一句话，说清楚对使用者意味着什么，而不是改了哪个函数
- 用户能感知的变化优先；纯内部重构不写进来
- 破坏性变更必须单独列出，并写明迁移动作

2.2 目录名就是命令名

这里有一条要记住的规则：目录名就是你输入的命令名。目录叫 release-notes，命令就是 /release-notes。SKILL.md 这个文件名是固定的，不能改。

现在打开任意一个项目，启动 claude，输入：

/release-notes

模型就会带着你写的那套规则，去整理当前的改动。你刚刚把一段每次都要口述的提示，变成了一条命令。

2.3 用 $ARGUMENTS 接住参数

固定的提示只是第一步。真正好用的命令能接住你临时补充的话。正文里写 $ARGUMENTS，它会被替换成你在命令后面输入的全部文字：

---
description: 把改动整理成面向使用者的发布说明。当用户要写发布说明、release notes 或 changelog 时使用。
---

把提供给你的改动整理成一份发布说明。$ARGUMENTS

规则：
- 按"新增 / 修复 / 破坏性变更"分三类，某类为空就省略该类
- 每条一句话，说清楚对使用者意味着什么
- 破坏性变更必须单独列出，并写明迁移动作

之后你就能这样用：

/release-notes 这次是面向内测用户的，语气可以轻松一点

那句补充会接在指令后面进入提示。除了 $ARGUMENTS 接住全部参数，你还能用 $1、$2 取第一个、第二个位置参数。

2.4 验证它真的能用

做完一个产物，养成立刻验证的习惯。测试触发有两种方式：

• 直接调用：输入 /release-notes，看它是否按你的三分类规则输出；
• 让模型自动调用：随便找个改动，问一句”帮我写下这次的发布说明”——如果它自动挂上了这个技能，说明你的 description 写对了。

第二种验证方式引出了整份教程里最关键的一个部件：description。它决定模型会不会在恰当的时候主动想起这个技能。第 4 章会专门拆解它。

你现在的成果：你有了第一个能用的产物。但它还很单薄——只是一段提示。接下来三章，我们把它升级成一个真正的技能：带结构、带数据、带模板、带脚本。