一句话理解
Claude 对 skills 的使用方式，不是像传统程序那样“先注册函数，再显式调用”，而是先把每个 skill 当作一个可发现的能力说明卡片，在任务真正相关时，再按需读取完整说明、附加资料和脚本。
整体流程
1. 启动时只加载摘要
每个 skill 都是一个目录，最核心的文件是 SKILL.md。这个文件顶部通常包含 YAML frontmatter，至少会写出：
namedescription
Claude 在启动阶段不会把所有 skill 的完整正文都塞进上下文，而是只预加载这些元信息。这样做的目的，是让模型先知道“有哪些能力”以及“什么时候该考虑使用它们”。
2. 收到任务后先做匹配
当用户发来一个请求时，Claude 会把当前任务和已加载的 skill 元信息进行比对。这个阶段的关键不是执行，而是判断：
- 当前请求是否和某个 skill 的
description高度相关 - 是否值得进一步读取这个 skill 的完整内容
如果没有命中，Claude 就按通用能力直接处理任务。
3. 命中后再读取完整 SKILL.md
一旦 Claude 判断某个 skill 与当前任务相关，它才会进一步读取该 skill 的完整 SKILL.md。这时真正进入的是该 skill 的正文说明，包括：
- 建议的处理流程
- 任务边界
- 默认实现方式
- 输出要求
- 何时继续读取更多文件
这一步相当于“从能力摘要进入操作手册”。
4. 需要更多细节时，再读附加文件
好的 skill 往往不会把所有细节都堆在一个文件里，而是把更长、更具体、只在特定场景下需要的内容拆到单独文件中，比如：
references/patterns.mdforms.mdreference.md
Claude 不会默认全量读取这些文件，而是只在任务确实需要时继续打开。这种机制通常被称为“渐进披露”，它能减少上下文浪费，也让 skill 可以不断扩展。
5. 需要确定性操作时，再执行脚本
有些能力不适合单靠语言模型推理完成，比如：
- 解析文件
- 提取结构化字段
- 生成导出产物
- 执行稳定的计算或转换
这时 skill 可以附带脚本。Claude 在理解了 SKILL.md 的指导后，可以选择运行 skill 目录里的脚本，把脚本当成实际工具来使用。
为什么这种机制有效
这种设计有三个明显好处：
- 节省上下文，因为启动时只加载 skill 摘要
- 更灵活，因为只有相关任务才会展开具体说明
- 更稳定，因为复杂步骤可以落到脚本执行，而不是完全依赖模型即时生成
用一个本地 skill 来理解
如果一个 skill 的 description 写的是“当用户需要联网搜索内容时使用”，那么 Claude 在启动时只会记住这一点。
只有当用户真的提出类似“帮我联网搜索一下最新的电影”这样的需求时，Claude 才会继续读取这个 skill 的完整 SKILL.md。如果正文又提到“当任务涉及结果文案模式时，再去读 references/patterns.md”，那 Claude 也会只在那个场景下继续展开。
总结
Claude 调用 skills 的本质流程可以概括为三层：
- 先加载 skill 元信息
- 命中后加载完整说明
- 必要时再加载附加文件或执行脚本
这使得 skill 更像一套可按需展开的“操作手册 + 工具箱”，而不是一次性全部注入上下文的大提示词。