如何创建好用的 Skill
从跑通的任务开始，写清流程、产物和检查方法。
先完成一次真实任务，记录哪些步骤需要专业知识、固定要求或工具操作，再把可复用的部分整理成 Skill。
什么任务适合写成 Skill
| 情况 | 例子 |
|---|---|
| 有固定产物和标准 | 公司报告模板、文章平台版本、可播放的视频。 |
| 有模型无法猜出的知识 | 业务约束、平台发布流程、项目专属的验收要求。 |
| 有需要稳定执行的步骤 | 文件转换、数据计算、格式校验、发布后的状态查询。 |
只是一句“回复简短”“注释用中文”，放在工具偏好或项目规则里就够了。普通计划和评审流程的取舍见 通用流程 Skill。
重复做过几次是一个有用信号，次数不是硬标准。更关键的是：任务是否稳定，要求能否说明白，是否有可以检查的结果。
先把流程跑通
以文章适配为例，先准备一篇你已有的文章，完成这几步：
- 明确发到哪些平台，需要 Markdown、HTML 还是图片。
- 列出哪些内容必须保留：观点、数字、引用、个人口吻。
- 做出各平台版本，打开文件检查排版和内容。
- 记录反复交代的要求，以及哪些处理步骤可以复用。
把能处理好的部分写进 Skill。没有跑通的生图、平台登录或发布步骤，先列明依赖和限制。
最简单的开始方式
让 AI 帮你写
工具已提供创建 Skill 的能力时可以直接用；需要独立安装时：
npx skills add anthropics/skills --skill skill-creator然后提供你的实际流程：
帮我创建 article-adapter Skill。
用途：将已有文章适配到公众号和小红书。
输入：原始文章、目标平台、需要保留的口吻。
输出：每个平台一份文件，列明修改内容。
要求：不新增事实、数据或第一人称经历；没有原文时不凭标题编写。
下面是我已经跑通的流程和样本：……从一个完整模板开始
---
name: article-adapter
description: 将已有文章适配为公众号和小红书版本，保留事实与口吻。用户提供文章并要求平台适配时使用。
---
# 文章适配
## 输入与产物
输入：文章正文、目标平台、口吻和需要保留的标题。
产物：每个平台一份 Markdown 文件，以及修改说明。
用户需要其他格式时，先确认现有工具能否导出。
## 执行步骤
1. 读取完整原文，识别观点、数字、引用和个人经历。
2. 确认目标平台和输出格式；缺少关键材料时指出缺什么。
3. 调整标题、段落和排版，保留原文事实，不编造引用或经历。
4. 保存为 wechat.md、xiaohongshu.md，只输出用户需要的平台。
5. 对照原文检查事实和观点，打开文件检查排版。
## 边界
不执行对外发布；需要发布时另按用户要求和账户权限处理。
没有完整原文时，不以推测补写。
## 失败处理
无法读取材料或输出文件时，说明具体原因和未完成步骤。文件放进与你工具对应的 Skill 目录。开放格式的 name、description 必需；详细结构见 Skill 拆解。
scripts、references 和模板怎么加
- scripts：做格式转换、统计或校验等确定性步骤。写清运行条件和失败信号。
- references：放长资料，主文件只链接当前步骤需要的部分。
- assets：放输出模板、样式或品牌资源。
- agents/openai.yaml：需要 OpenAI 展示、调用策略或工具依赖元数据时添加，详见 平台扩展。
先使用成熟工具；确实需要固定重复动作时再写脚本。Skill 指导调用工具，并不自动安装依赖或取得账户权限。
测试和优化
用小样本检查加载和结果。下面是评估项目，具体结果需要你实际记录。
| 样本 | 检查什么 |
|---|---|
| 正常文章，要求适配 | 被正确调用，输出指定平台文件，事实和口吻保留。 |
| 只问一个普通问题 | 不无故调用文章适配流程。 |
| 只有标题，没有正文 | 指出缺少原文，不编造文章。 |
| 原文有数字、引文和经历 | 修改格式后仍与原文一致。 |
| 材料无法读取或依赖缺失 | 说明失败原因，不把任务标成完成。 |
| 只要求一个平台 | 只生成需要的版本。 |
先看 Skill 是否被发现，再看是否被选中，最后看是否执行正确。不要把所有问题都归因于触发词。
有 Skill 和没有 Skill 的对照
用同一份输入、相同工具和模型，分别完成一次任务。记录：
- 输出是否达标，返工在哪里。
- 需要补充哪些说明。
- 实际对话轮次、耗时和工具失败。
多试几份不同材料，才能判断改进是否稳定。评估只填真实结果；不能预先写“节省一半 Token”或保证轮次下降。
根据问题修改
刚才的小红书版本新增了一段原文没有的个人经历。
请修改 article-adapter：保留原文口吻，但不得补写第一人称经历。
再用同一份原文检查修改后的结果。修改之后同时检查相关任务和无关任务，避免描述越来越宽，反而抢走其他任务。
团队与复杂流程
团队共享的 Skill 放在项目里，跟着代码审阅和维护。项目规则负责长期约束，Skill 引用它们，不再重复写一套冲突规则。
跨多个外部系统时，写清步骤依赖、所需权限、失败后停在哪、怎样确认远程操作完成。上传草稿、创建任务和真正对外发布是不同结果，分别检查。
如果流程要求确定性拦截或强制顺序，需要脚本、Hook 或工具权限机制；仅写在 Skill 正文中不能保证强制执行。
分享你的 Skill
分享前补上：用途、适用工具、依赖、样本任务、检查方法和许可说明。
可以放到公开仓库，或分享完整文件夹的 Zip。别人通过仓库安装时，使用实际 Skill 名称：
npx skills add your-account/your-repo --skill article-adapter第三方 Skill 修改后保留自己的版本，避免更新覆盖。私有仓库先配置认证，见 命令行指南。
下一步
- 文件结构和平台扩展 → Skill 拆解
- 调用失败 → FAQ
- 分享和更新 → 命令行指南
- 商品交付 → 把 Skill 当小商品卖