先看结论
少囤积，多沉淀。
这份笔记从视频《Skill 入门教程：删掉别人的 Skill，我来助你！》及一份相关讨论出发。对我最有用的提醒是：先完成真实任务，再把其中可重复、可验证的做法写下来。
Prompt 解决这一次怎样做；Skill 记录这一类任务以后怎样做，并让 Agent 在需要时找到它。
下文的“视频观点”依据所提供对话中的转述整理，并非视频逐字稿；对 Skill 格式和机制的说明另与文末官方资料核对。
观点辨析
视频提醒了什么？哪里还要补一层？
通用 Skill 能提供起点，但个人审美、项目约束和反复踩过的坑，最终要由自己的工作流来记录。把“装更多”当成进步指标，容易忽略实际任务效果。
“写了步骤的提示词”是有用的入门比喻，却不完整。一个 Skill 可以包含指令、按需阅读的资料、模板和可执行脚本。
第三方 Skill 也可能很有价值。通用能力可以借鉴现成实现；真正需要自己写的，是别人不知道的目标、约束和成功经验。
Skill 的数量没有通用的最佳值。更多相似的名称和描述会增加选择与维护成本，但是否保留某个 Skill，仍应看它能否在真实任务中稳定起作用。
结构与加载
一个 Skill 怎么被找到、打开、使用？
开放的 Agent Skills 规范规定：目录至少要有一个 SKILL.md，其中的 name 和 description 帮助 Agent 判断它是否相关。scripts/、references/ 和 assets/ 是常见的可选目录。
判断这项任务是否需要该 Skill。
获取步骤、边界和进一步的文件引用。
只为当前任务读取相关内容、运行所需代码。
这就是“渐进式披露”：先给发现所需的少量信息，再在任务真正需要时展开细节。它解释了为什么描述要准确，也解释了为什么长篇参考资料适合从主文件拆出去。
概念地图
Skill、Tool、MCP、Plugin 不是同一层。
这些词在各家产品里的边界不完全一致。为了学习，我把它们按回答的问题区分：
| 概念 | 主要回答 | 处理 GitHub Issue 的例子 |
|---|---|---|
| 项目指令 | 这个项目有哪些长期约束？ | 仓库规范、发布要求、测试门槛 |
| Skill | 这一类任务怎么做？ | 复现、定位、修复和复盘的流程 |
| Tool / MCP | Agent 能读取什么、执行什么？ | 读取 Issue、搜索代码、提交评论的接口 |
| Plugin / 扩展 | 如何把能力组织、安装和分发？ | 把多个 Skill 与外部工具放在一起 |
这是帮助记忆的功能划分，不是要求所有平台都采用相同术语或产品结构。
跨平台视角
格式正在靠近，运行方式仍要分别看。
Agent Skills 已有公开规范，Anthropic、OpenAI、Gemini CLI 和 Microsoft Agent Framework 的资料都能看到类似的文件式思路。一个结构清楚的 Skill，因此更容易迁移。
触发方式、工具权限、脚本环境、依赖和外部服务连接仍取决于宿主产品。迁移时应先检查这些条件，再用实际任务验证。
动手方法
先跑通一次，再问能否写成 Skill。
- 选一个反复出现的任务。
例如同一类论文复现、项目发布或图表校验；明确输入、完成标准和常见失败。
- 完成真实任务并记录证据。
保留有效步骤、需要人工判断的地方、失败原因，以及可复用的脚本和模板。
- 写出触发条件和最短流程。
让
description说清“做什么、何时用”；让SKILL.md只承载核心方法。 - 用新任务验证并修订。
如果 Agent 误触发、遗漏步骤或脚本失效，就修改相应描述、流程或资源。
读它的说明、脚本和依赖，确认会访问哪些文件与服务。对于能运行代码或接触凭据的 Skill，来源与权限和功能一样值得检查。
最终要积累的不是“拥有多少 Skill”，而是哪些经验已经变成了下一次可以检验的方法。
延伸阅读
来源与核对
- 《Skill 入门教程：删掉别人的 Skill，我来助你！》：这份笔记的讨论起点；视频观点来自所提供对话的转述。
- Agent Skills Specification：目录结构、元数据和渐进式加载。
- Anthropic：Equipping agents for the real world with Agent Skills：设计思路、迭代建议及第三方 Skill 风险。
- OpenAI：Skills、Gemini CLI：Agent Skills、Microsoft Agent Framework：Agent Skills：各宿主的实现资料。