模型越来越强，但真实工作还需要程序性知识和组织上下文。Anthropic 用一种极简的格式回答这个问题：
一个文件夹、一份 SKILL.md、加上按需加载的脚本和资源。
Skill = 一个带 SKILL.md 的文件夹。SKILL.md 的 YAML 头里只放 name 和 description， 启动时会被加载进系统提示，作为所有 skill 的"目录"；正文和附带的脚本 / 文档，只有当 Claude 判断这个 skill 与当前任务相关时才会被读进上下文。
关键设计是渐进式披露：上下文里始终只装"当前需要"的那部分，所以一个 skill 可以打包任意多的程序性知识，而不会撑爆 context window。 Skill 还可以包含可执行脚本，让 Claude 把那些"代码做更可靠"的事情交给确定性的代码去做。
模型能在通用任务上表现很好，但落到具体团队、具体流程时， 总是缺少"那一份只有你才知道的程序性知识"。
随着模型能力变强，我们已经可以构建在真实环境中独立行动的通用 Agent —— Claude Code 就是这样一个例子，它能借助本地代码执行和文件系统跨领域完成复杂任务。 但越是通用，越需要可组合、可扩展、可移植的方式把领域专家的知识喂给它。
Anthropic 的回答是 Agent Skills：把一份份程序性知识打包成"一个文件夹 + 一份 SKILL.md"的形式，让 Agent 在需要时自己去发现和加载。 作者把这件事比作给新员工写入职指南 —— 你不会一次性塞所有制度给新人，而是先给一份目录，让他在遇到问题时再翻特定章节。
最简形态：一个文件夹，里面有一份 SKILL.md，开头是一段 YAML frontmatter 描述这个 skill 的身份。
文章中举了 Claude 文档编辑能力背后的 PDF skill 作为例子。Claude 本身已经知道很多关于 PDF 的事情， 但直接操作（比如填表单）还差一截。PDF skill 就是来补这部分能力的。
当一个 skill 的内容多到一份 SKILL.md 装不下，或某些章节只在特定场景才需要时， 就把它们拆成 SKILL.md 旁边的附带文件，在主文件里按名字引用。 Claude 只在真的需要时才去读那些附带文件。
每个 SKILL.md 必须以 YAML frontmatter 开头，至少包含 name 和 description。 这两段会在 Agent 启动时被加载进系统提示，作为「skill 目录」的索引。
这个 description 写得好不好，直接决定 Claude 能不能在需要的时候联想到这个 skill。 作者特别强调：把 name 和 description 当成触发条件来写。
从"目录"到"章节"再到"附录"，Claude 只读它当下需要的那一层 —— 这是 Skills 能做大、做多、做杂的根本原因。
作者打了一个比喻：好的手册从目录开始，再到具体章节，最后才是详细附录。 渐进式披露就是把这套阅读节奏直接搬进了 Agent 的 context window。
一个 Agent 配了 n 个 skill，并不意味着上下文里要塞 n 份手册的全文。 实际上常驻的，只有每个 skill 的一段元数据。
forms.md。
脚本则可以"运行而不读"。
点上方任意一步，看看用户问"帮我填这份 PDF"时，Claude 的上下文是怎么逐层打开的。
大模型擅长的事很多，但排序、解析二进制、读取 PDF 字段这种事， 让模型一个 token 一个 token 地生成既慢又贵，还不一定对。
在 PDF skill 里，Anthropic 预先写了一段 Python 脚本，用来读取 PDF 并提取所有表单字段。 Claude 可以直接运行这个脚本，既不用把脚本读进上下文，也不用把 PDF 读进上下文。 因为代码是确定性的，这个流程稳定可重复 —— 这是任何 token 生成都给不了的保证。
把整份 PDF 塞进上下文，让模型一格一格地"看"出哪里是字段、哪里是签名位 —— 慢、贵、还可能漏。
对每一份新 PDF 都要重来一次。
Claude 看到 SKILL.md 里写的"用 extract_fields.py 读取字段"， 直接 bash 调用脚本，只有结果（字段列表）回到上下文。
点开任一卡片，看看它对应的具体做法。
Skill 给 Claude 注入的是"指令 + 代码"，所以它能放大能力，也能放大恶意。 但同样因为格式简单，它有非常大的演化空间。
Skills 是一个简单的概念，对应的是一个同样简单的格式。 正是这种简单，让组织、开发者和最终用户都能定制自己的 Agent，赋予新能力。 作者最后一句话很克制：Skills 一开始只是给文件夹的人写的；接下来轮到 Agent 自己来写文件夹了。