同样的话，你每周都要跟 WorkBuddy 说一遍：周报必须四段式、表格要保留两位小数、对外邮件先称呼再正文再落款、产品名不能写错大小写......
烦。更烦的是，它有时记得有时忘，你还得翻聊天记录找「上次我是怎么叮嘱的」。
Skill 解决的就是这个：把一次讲清楚的做法，打包成可反复调用的 SOP/手册包。不是每次从零教，而是「这类活，按我们家的规矩来」。
Skill 和一次性 Prompt 有啥不同
Prompt（一次 Task） 像临时派活：「把这份表汇总一下，注意合计行。」干完就散，下次还得重说。
Skill（可复用做法包） 像版本化的 runbook：里面有步骤说明（SKILL.md）、可选脚本、模板、样例。WorkBuddy 接到相关任务时，先翻这本手册，再动手。
技术相对照：
- 聊天框 = 通用模型，没有你们公司的习惯。
- 普通 Task = 每次把参数和约束写进命令行。
- Skill = 固化的 playbook，执行前自动加载，不用你重复讲第三遍。
Skill 通常包含：名称和简短描述（让你知道啥时候该用）、详细规则正文（用到才加载）、以及可选的脚本或模板文件。这叫渐进披露------列表里先看标题和简介，真用到再展开全文，不占无谓上下文。
纸质岗位手册教人怎么做；WorkBuddy 的 Skill 是手册 + 执行者。手册里写「汇总表保留两位小数」，它读 Skill 后生成 Excel 时会真的按两位小数来------不是只看一遍文档然后自由发挥。但手册里写不清楚的，它也会卡。Skill 质量决定输出质量：步骤模糊、样例缺失、边界没写，照样返工。维护 Skill 跟维护内部文档一样，要有人偶尔更新。
Skill 能帮你干什么
- 补公司流程知识。 报销附件命名规则、品牌用词表、内部文档标题格式------写进 Skill，比每次粘贴一段「注意事项」稳。
- 固定工作流。 「收齐发票 → 核对金额 → 生成汇总表 → 输出待审清单」这种重复链路，Skill 把顺序和检查点钉死。
- 减少重复叮嘱。 你说过一次的话，沉淀成 Skill，团队其他人用斜杠命令也能调用同一套标准。
- 经验资产化。 老员工脑子里的「我们以前怎么做」，变成可 diff、可版本管理的文件，新人不用靠口头传承。
怎么用：市场、上传、斜杠调用
WorkBuddy 支持从 Skill 市场安装现成的（通用写作、表格处理之类），也支持把自己或团队的做法打包成 zip 上传 。上传前按规范组织：根目录放 SKILL.md，说明名称、描述、适用场景；需要的话附上模板和脚本。
调用方式 一般是输入斜杠命令，比如 /weekly-report，后面再跟本次具体材料或微调说明。Skill 提供「怎么做的规矩」，你仍然要提供「这一次的具体输入」。
用不上的 Skill 可以关闭或卸载，避免列表太长找错。常用的留几个就够起步，不用的收起来。
渐进披露：为什么列表里只见标题
Skill 市场或本地列表里，通常只显示名称和一行描述 ------像书架上的书脊，让你判断「是不是这本」。真正执行任务、匹配到某个 Skill 时，才加载 SKILL.md 全文和相关脚本。
这样设计是为了省上下文、降干扰。几十个 Skill 全展开，反而找不到重点。挑 Skill 时看描述是否命中场景；命中了再调用，细节交给运行时加载。
团队里谁该维护 Skill
个人 Skill：自己用自己改。团队 Skill：建议指定 owner，跟内部文档 owner 一样------模板变了、品牌色改了、财务要求改了，owner 更新 SKILL.md，版本在文件名或文内记一笔。
没有 owner 的 Skill，半年后就跟旧版 PPT 模板一样，用着用着全员怀疑「是不是工具不行」，其实是手册过期。
写一个 Skill 从哪开始
不必一次完美。推荐路径：
- 先有一次成功的 Task。 演练目录里跑通，验收过了，说明你的六要素描述本身是对的。
- 把「每次都一样的部分」抽出来。 格式、禁忌、步骤顺序、输出文件名规则------这些是 Skill 正文。
- 把「每次会变的部分」留在 Prompt。 具体文件名、日期、客户名------调用 Skill 时再填。
- 试调用并迭代。 故意用边界 case 测：缺字段、空文件、负责人未知，看 Skill 里有没有写「这时怎么办」。没有就补一条。
团队共用时，约定 Skill 命名和描述，避免三个人三个 /report 不知道选哪个。
调用时 Prompt 和 Skill 怎么分工
记住一句：Skill 管规矩，Prompt 管这次。
Skill 里写「周报四段：本周完成、下周计划、风险、需协调」；Prompt 里写「本周数据在 week12.xlsx，风险重点写供应链延迟」。规矩不必每次重复，材料每次不同。
斜杠命令后面跟的那几句，就是本次 Prompt。别在 Skill 里硬编码会变的日期和客户名；别在 Prompt 里重复 Skill 已有的格式说明------两边分清，描述又短又稳。
从市场安装 vs 自己上传
市场里的 Skill 适合通用场景：Markdown 整理、表格清洗、常见文档转换。拿不准时先装一个轻量的试跑，看 SKILL.md 是否符合你习惯。
公司特有流程------内部模板、审批用语、字段命名------几乎一定要自己写或改 再上传 zip。直接拿市场 Skill 硬套内部规范，往往要大量口头补丁，不如一开始就把补丁写进 SKILL.md。
常见坑
- Skill 写太长像论文 → 执行时加载慢、抓重点难。核心规则放前面，细节放附录或分节。
- 该进 Skill 的还在口头说 → 没沉淀，下次还是重复。固定规矩进 Skill，一次性例外留 Prompt。
- 从不更新 → 公司改了模板，Skill 还是旧版，产物集体跑偏。手册要有 owner。
- 装太多从不卸载 → 斜杠列表一长，误调用概率上去。常用的留三五个就够起步。
- 把 Skill 当万能 → 它管「怎么做」，不管「做不做」。涉密、涉合规的决策仍在你。
- Skill 之间打架 → 同时启用两个风格冲突的 Skill，产物可能四不像。一次 Task 聚焦一个主 Skill，必要时在 Prompt 里声明「以某某 Skill 为准」。
人工闸门：Skill 替不了的部分
Skill 固化的是流程和格式 ，不是业务判断 。例：Skill 写「待办标注负责人」，但原文没有名字------它应标 @待定，你补全后再发。Skill 写「对外邮件经主管确认」，系统不会自动替主管点头，要你或主管真的确认。
上传团队 Skill 前，自己先跑几遍；涉及脚本自动改文件的，脚本逻辑也要人看过。Skill 是放大器：规矩写对了放大效率，写错了放大错误。
从市场安装的第三方 Skill，敏感任务前先看 SKILL.md 里会读哪些路径、会不会外传------跟装任何办公插件同一个谨慎度。
复杂任务有时需要多个专长一起会诊（后续能力）；Skill 是事先写好的单份手册，日常重复活用 Skill 即可。别第一天就把所有活都塞进一个巨型 Skill。
Skill 用得顺的团队，共同点是：先有个人练熟的六要素，再把六要素里不变的部分抽成手册。 跳步直接写 Skill，往往反复改 SKILL.md，不如先跑通两三次 Task 来得实在。
小结 ：Skill = 可复用的 SOP 包：SKILL.md 讲规矩，可选脚本模板帮执行；用斜杠调用，一次沉淀、反复少废话。Prompt 管这一次，Skill 管这一类。如果你发现自己跟 WorkBuddy 重复第三遍同样叮嘱，停一下，把那句话写进 Skill。先从一个小 Skill 开始------比如「自家周报格式」或「文件名命名规范」------比一口气建十个半成品实用得多。也可以问：这段话我是不是已经复制粘贴给 AI 超过两次了？是的话，它就该进 Skill 了。手册不必一次完美，但要有人记得更新；跟团队共享前，自己在演练目录试几遍，比上线后集体返工体面。