br/>正文怎么写没有死规定，但好的写法是：先一句话说这个Skill解决什么，再用编号列出步骤，能给例子就给例子，能附模板就附模板。比如周报Skill的正文，可以写"第一步列本周完成、每条带负责人，第二步列下周计划，第三步语气正式，第四步结尾附一个三列表格"，再贴一份填好的样板周报让AI照葫芦画瓢。
有一条硬建议要记住：正文别超过500行。太长了AI读着费劲、也占地方，正确的做法是把不常用的细节拆到references子目录里，正文只留主干，用到了再让AI去翻。这背后的道理就是下面2.5节要讲的渐进式披露。
2.4 三个可选子目录：scripts、references、assets

这三个子目录是Skill比prompt强的地方，各有分工。
scripts放能直接运行的小程序，Python、Bash脚本都行。凡是确定性的脏活，排序、求和、格式转换、批量改名，都适合写成脚本扔这儿。关键好处后面会反复讲：AI是去运行它，不是去读它，脚本的代码本身根本不进AI的脑子，只有运行结果回来。
references放更详细的参考文档，都是Markdown。把正文里塞不下、又不是每次都用的细节放这儿，比如一份完整的格式规范、一张容易出错的对照表。AI只在真用到那一刻才去读对应文件，平时不碰。
assets放静态素材，模板、图片、数据文件，比如一个现成的Excel模板、一张查找表。脚本和正文需要时直接引用它们。
引用这些文件时有两条小规矩：用相对路径（从Skill文件夹算起），目录别套太深，一层就好，别搞嵌套分类。
2.5 Skill 是怎么被加载的：渐进式披露

这是整篇文章最该搞懂的机制。AI不会把你所有Skill一股脑全读进脑子，那样既慢又乱。它用的办法官方叫渐进式披露（progressive disclosure），翻成人话就是：用到哪本才翻哪本，用到哪页才翻哪页。分三层。
第一层，元数据。AI一开机，只把每个Skill的name和description读进来，正文一概不读。这一层每个Skill只占大约100个token，就是一句话简介的量级。所以你哪怕装了几十个Skill，平时也几乎不占地方、不拖慢它。
第二层，正文。当你说的任务跟某个Skill的description对上了，AI才把那一个Skill的SKILL.md正文完整读进来，照着做。这一层官方建议控制在5000个token、500行以内，就是为了读得快。
第三层，资源。只有真用到时，AI才去读scripts、references、assets里的具体文件。脚本更特殊，它是被运行，源码不进上下文。
三层下来，效果是任何一刻进AI脑子的内容都尽量少。记住这个"少喂"的特点，第六章回答"黑箱"问题时全靠它。
2.6 看一个官方真 Skill：PDF 技能长什么样

光说不练没体感，来看Anthropic官方那个处理PDF的真Skill，它就在GitHub的anthropics/skills仓库里。它的文件夹是这样：

它的description写得很见功力，几乎把所有可能的触发场景都列了：读取或抽取PDF文字表格、合并拆分、旋转页面、加水印、新建、填表单、加解密、抽图片、对扫描件做OCR，只要用户提到 .pdf文件或要生成PDF，就用这个Skill。这就是好description的样板，把"什么时候该用"写得密不透风。
正文则是一份PDF处理指南，讲该用哪个Python库、哪个命令行工具，并且明确说"填表单看forms.md，进阶看reference.md"，把细节甩给了references文件。八个脚本则是确定性的活，比如抽取表单字段那个，AI直接运行就拿到结果，不用把整个PDF读进脑子。一个标准的渐进式披露布局，正文管主干，references管细节，scripts管脏活。
顺带说一句官方都提供了哪些现成Skill。claude.ai和API上自带四个文档类预建技能：pptx做PowerPoint、xlsx做Excel、docx做Word、pdf处理PDF。GitHub仓库里还开源了一批Skill，比如帮你做Skill的skill-creator、帮你搭MCP服务的mcp-builder、查Claude API文档的claude-api、做网页测试的webapp-testing、写内部沟通文档的internal-comms等等，照着改是最快的入门法。
2.7 哪些事不适合做成 Skill

知道什么该做成Skill，也得知道什么不该，免得白费劲。有几类事做成Skill并不划算。
一次性的事不必做。你这辈子可能就用一次的需求，直接写句prompt就完了，专门建个文件夹反而麻烦。Skill的价值全在"反复用"，用一次就摊不平做它的成本。
要求每次都变的事做不了。Skill装的是固定流程，如果你每次的要求都不一样、没有可沉淀的套路，那它就没东西可写。它适合"格式固定、内容变"，不适合"格式也天天变"。
纯粹查实时信息的事它管不着，那是MCP的活。比如"查一下今天的汇率""看看我邮箱里最新一封信"，这些要的是连接外部数据，得靠MCP那套接口，Skill帮不上忙。一句话，Skill管"怎么做事的固定知识"，不管"实时去哪取数据"。

三、手把手做你的第一个 Skill

理论够了，这一章带你从零做一个能跑的Skill。就拿"整理周报"这个最常见的需求开刀，每一步给你能直接抄的内容。


3.1 选题：找一件你反复做的事

第一个Skill别贪复杂，挑一件你确实在反复做、而且每次规矩都差不多的事。判断标准很简单：如果你发现自己在不同对话里一遍遍打同一段prompt，那就对了。
适合开刀的典型有这些。按固定格式写周报月报，按公司口径回客户邮件，把杂乱的客户名单清洗成统一格式，按一份清单审查合同条款，把会议录音整理成"结论加待办加负责人"的纪要，按品牌调性写一批文案。这些事的共同点是要求固定、只有内容每次不同，最适合做成Skill。下面我们用周报。
3.2 第一步：建文件夹和 SKILL.md

先建一个文件夹，名字就叫weekly-report，记住文件夹名以后要和SKILL.md里的name一致。在文件夹里新建一个文本文件，命名为SKILL.md（建议大写，最稳）。
把下面这些内容原样抄进去，这就是一个最小可用的Skill：
---
name: weekly-report
description: 按公司格式整理每周工作周报。当用户说"写周报""周总结""整理本周工作"时使用。 ---
# 周报整理
把用户给的零散工作内容，整理成公司标准格式的周报。
## 步骤
1. 先写"本周完成"，每条一句话，句末用括号标注负责人。
2. 再写"下周计划"，格式同上。
3. 全文语气正式，不用感叹号和表情。
4. 结尾附一个三列表格：项目、进度、风险。
## 示例
本周完成： - 完成X模块联调，进入测试（张三）
下周计划： - 上线X模块，跟进线上数据（张三）
到这一步，一个能用的Skill已经做完了。全是大白话，没有一行代码，你写的就是一份你早就会的操作说明，跟编程不沾边。
3.3 第二步：把 description 写对，这是触发的唯一钥匙

第二章说过，description是AI决定用不用这个Skill的主要依据。这句话写得好不好，直接决定你的Skill会不会被想起来，所以单独拎出来讲。
道理在于AI平时只看得见每个Skill的name和description（第一层加载）。你说"帮我整理一下这周干的活"，AI扫一遍所有description，看哪个对得上。如果你的description写得含含糊糊，它就认不出来，这个Skill就被晾在一边，永远不被调用。
对比一下好坏。差的写法："周报工具。"这句话既没说清干什么，也没说什么时候用，更没有能对上"这周干的活"