SKILL.md 是什么
一个技能就是一个目录，里面放一份用自然语言写的 SKILL.md 指令文件。Agent 装上技能后读这份文件，从而知道什么时候该用它、按什么步骤执行、依赖什么。没有编译步骤，没有 SDK——文件本身就是程序。
这个命名约定在现实里并不完全统一。我们依赖的三篇报道里有两篇写 SKILL.md，一篇写 skill.md。我们用大写形式，同时建议你去确认目标 Agent 到底认哪一种，而不是默认。
决定结果的三个部分
官方发布流程的已报道行为是：创作服务平台会解析你的 Markdown，自动提取名称、简介和正文，然后在审批前让你手工填写编号。这个形态本身就说明了先被读到的是什么。
- 触发段这个技能什么时候该触发？如果审核看完第一段还答不上来，文件里别的内容救不了它。要写情境，不要写技术。
- 步骤清单按顺序到底做了什么，以及在哪一步要求人工确认。一份没有任何确认点的步骤清单，读起来就是无人值守的自动化，这比「生成草稿＋人工审核」的循环难通过得多。
- 依赖段要跑起来必须先有什么：工具、凭据、文件路径、网络访问、登录会话。这一段是作者最容易跳过、审核最需要的。
触发条件怎么写才在该触发的时候触发
含糊的触发条件是我们在读过的技能里见到最多的缺陷。「帮助进行内容创作」会在一次毫不相干的任务中间被触发，然后产出噪音。「当用户要求把一个商品页变成三篇小红书笔记草稿，含钩子、正文和行动号召时使用」会在该触发的时候触发，其余时候保持安静。
三条在实践中站得住的规则：
- 写清楚产物，不要写感觉。「一个商品页」「一份 CSV 导出」「一张评论区截图」——具体的输入才让触发条件可测试。
- 把否定情况也写上。一句「什么情况下不要用」，能挡掉的错误运行比三句正面描述还多。
- 说明产出是什么。如果产出是草稿，就写「草稿」；如果产出会被发布，也要写明，并且写明由人工确认后再发布。
把依赖说明白
最关键的依赖是「会话」。报道记录过一种安装流程：技能会驱动一个真实的登录浏览器。我们数据集里那些把这件事写得清清楚楚的仓库，恰恰是最容易评估的。请像写数据库依赖那样写它——作为前置条件，而不是脚注。
第二件要说清楚的是平台当下实际接受什么。创作服务平台的已报道行为是：只解析 Markdown，脚本类文件会被过滤。所以一个依赖 Python 或 Node 的技能，必须写明「脚本不存在时该怎么办」。只写一句「需要 Python」而不给退路，会让每个读者拿到一个只能跑一半的技能。
可以直接开抄的骨架
下面不是官方语法——我们能找到的来源里没有任何一份记录了必需的字段结构。这是「同时被人和模型读」之后活下来的那种结构。
# <技能名称>
## 什么时候用
- 使用时机：<产物 + 目标>
- 不要用：<最容易误触发的相邻任务>
- 产出：草稿 | 清单 | 报告 | 已发布动作（写明是哪一种）
## 需要用户提供的输入
- <输入> —— 必填／选填，以及它长什么样
## 步骤
1. <动作>
2. <动作>
3. 停下来，把结果给用户确认后再继续
## 依赖
- 工具：<解释器、CLI、模型>
- 会话：无需 | 只读公开页面 | 登录浏览器
- 网络：无需 | 公开读取 | 需鉴权写入
## 失败处理
- 如果缺少 <某项依赖>：<改用别的做法>
- 永远不要：<这个技能绝对不能做的动作>
提交路径
发布走小红书创作服务平台，而且只能在网页端完成，App 暂不支持上传。已报道的流程是：进入创作服务平台，找到 Red Skill 入口，上传一个 Markdown 文件或一个含 Markdown 的文件夹，由系统自动解析名称、简介与正文，自己填写编号，然后提交审批。审批通过后，一篇笔记就能把它作为组件挂上去。
有两个运营事实值得提前规划。上传功能当时处于灰度测试，而复制口令功能已对所有人开放，所以可用性可能因账号而异。另外，编号不是自动生成的：请起一个你半年后还能看懂的编号，因为所有安装命令里都会带着它。
提交前的自检清单
- 陌生人能预判触发时机吗？只读你那一段「什么时候用」，然后判断自己能不能说出它什么时候触发、什么时候不触发。
- 有没有确认点？任何会改变你本机之外状态的步骤，都要在文件里写成一道人工闸门。
- 会话要求写了吗？如果需要登录浏览器，那它就是依赖段的第一行。
- 缺依赖时它还活着吗？每一项依赖都应该配一句「那就改用什么」，哪怕答案是「停下来告诉用户」。
- 输入写具体了吗？「一个商品页」比「一些内容」好。审核会装上它，然后拿你写的字去试。
- 有没有写「永远不做什么」？一句明确的禁止清单，是一个技能文件能提供的最便宜的信任信号。