跨工具复用：一处写，处处用
上一篇我们把发文章检查的 Skill 拆开了：正文只留步骤和判断，脚本、规则和模板各归其位。一个 Skill 变清爽之后，下一个问题马上就来了：这个 Skill 只在现在这个工具里能用吗？换一个工具，是不是又要重写一遍？
先把结论放在前面：不用重写。Skill 本质上就是一组文件，文件本身不属于任何一个工具。 只要你写的 Skill 不绑死在某个工具特有的功能上，写好一份，就能在多个支持 Skill 的工具里接着用。真正要处理好的，是“怎么让多个工具共用同一份”，而不是“怎么写第二份”。
一、为什么一个 Skill 能跨工具用
一个 Skill 能被带走，靠的是三点，前三篇其实都已经讲过了，只是当时没点破。
- 它就是文件。 一个文件夹、一个 SKILL.md，加上 scripts、references、assets，都是普通的文件和纯文本。没有数据库，没有插件安装包，没有哪个工具私有的格式。文件能复制，Skill 就能搬家。
- 触发的约定是通用的。 每个工具判断要不要用某个 Skill，靠的都是 SKILL.md 顶部的 name 和 description：写了“做什么、什么时候用”，工具读到就知道该在什么时候翻它。这份约定不属于某一个工具，换工具也一样认。
- 正文写的是做法，不是按钮。 正文里的步骤是“核对标题有没有错别字”“运行脚本检查链接”，是人话写的做法，不是“点某个工具的某个菜单”。做法换个地方照样成立，按钮换个地方就找不到了。
反过来想，什么时候一个 Skill 跨不了工具？就是它写死了某个工具才有的东西：正文里写“点左上角的某某按钮”，脚本里调了某个工具独有的接口。这样的 Skill 不是 Skill 写错了，是写的时候把“做法”和“工具”绑在一起了。做法写进 Skill，工具的事留给工具，复用才成立。
二、真正不一样的三件事
说“不用重写”，不是说“什么都不用改”。换一个工具，有三件事确实不一样，提前知道就不会手忙脚乱。
- Skill 放在哪。 每个工具都有自己放 Skill 的目录，位置各不相同。有的在用户主目录下的固定文件夹里，有的在项目的某个子目录里。搬家第一步，就是先查这个工具的说明，找到它认的那个目录，再把 Skill 文件夹放进去。放错地方，工具根本看不到它。
- 工具怎么发现它。 有的工具启动时会自动扫描 Skill 目录，有的要你在设置里注册或导入，有的只认项目里的 Skill、不认全局的。这一步各工具的规矩不同，照着各自的说明走一遍就行，不用改 Skill 本身。
- 脚本在什么环境里跑。 scripts 里的脚本换了工具、换了机器，运行环境可能不一样：Python 在不在、依赖装没装、脚本有没有执行权限。Skill 搬过去之后，第一件事就是跑一次脚本，确认它在新地方也能跑通，别等到真正要用的时候才发现跑不起来。
这三件都是“搬家时的安置问题”，不是“重写问题”。Skill 的正文、描述、脚本逻辑都不用动，动的只是放哪里、怎么让工具看到它、在新环境里验证一次。
三、做法：一个源头，多处引用
多个工具共用一个 Skill，最容易踩的坑是：每个工具里都复制一份，改的时候只改了其中一份。 刚开始没感觉，过一个月，两个工具里的同一个 Skill 已经不是同一个版本了：一个修了链接检查的规则，另一个还用着旧规则；一个加了新步骤，另一个没有。名字一样，做法不一样，这就不是复用了，是分叉。
避免分叉的办法只有一句话：只留一个源头，其他地方都引用它。
具体做法是，先给你的 Skills 找一个固定的家，比如主目录下的一个 skills 文件夹，所有 Skill 都住在这里，这是唯一的源头。然后每个工具那边，不复制文件，而是用链接或引用指向这个源头：支持符号链接的，用链接把工具的 Skill 目录指到源头；不支持链接的，复制过去也可以，但要立一条规矩——改只在源头改，改完再同步复制一次，并且记下来这次同步改了什么。
这条规矩的价值，平时看不出来，改第三次、第五次的时候就出来了。源头只有一个，改一处就等于全改了；没有源头，改一处只是改了一处，剩下的迟早会忘。
另外一个小习惯：Skill 的描述和正文里，尽量别写具体工具的名字。写“在用户说要发布文章时使用”，不要写“在某某工具里说要发布文章时使用”。描述越不绑工具，换工具时要改的东西就越少。
四、动手：把上一篇的 publish-checklist 装到两个工具里
拿上一篇拆好的 publish-checklist 练一次，目标是：同一个 Skill，在两个工具里都能触发，改一次，两边都生效。
- 先把 publish-checklist 整个文件夹，放到你定的那个固定位置，比如主目录下的 skills 文件夹里，这里就是它唯一的源头。从这一步起，改 Skill 只改这里。
- 打开第一个工具的说明，找到它放 Skill 的目录，把源头链接过去，或者按它的要求导入一次。导入完，在这个工具里说一句“检查一下这篇文章能不能发”，看它会不会翻出 publish-checklist，会就说明发现这一步通了。
- 换第二个工具，重复第二步：找到它的 Skill 目录，链接或导入同一个源头，再用同一句话触发一次。两个工具触发的应该是同一个 Skill，步骤、脚本、模板都一样。
- 回到源头改一处，比如在 SKILL.md 里加一步“核对作者名字有没有写错”，保存后，分别在两个工具里再触发一次。两边都出现新步骤，这次复用才算真的通了；如果只有一边变了，说明另一边用的还是旧副本，回去检查它的引用是不是指向了源头。
练完这一次，你手里就有一套能复用的做法了：以后每写一个新 Skill，都是先写好、放进源头、再链接到各个工具，不用每个工具重写一遍。
五、什么时候别照搬
复用虽好，也有三条边界，碰到了就别硬搬，改一改再用。
- 脚本调了某个工具独有的东西。 比如脚本里调了某个工具才有的接口、读了它特有的配置文件，换个工具就跑不起来。这种脚本要单独处理：要么把那部分抽出来，写成两个工具各自的小适配；要么接受这个 Skill 只在那个工具里用，别为了复用把它改坏。
- 两个工具的权限不一样。 一个工具允许 Skill 读写文件、跑脚本，另一个默认不允许，或者每次都要你点头。Skill 本身没变，但跑起来需要的授权变了。搬过去之后先按新工具的规矩走一遍授权，别默认它和原来一样。
- 触发的说法不一样。 不同工具里，你说话的习惯可能不一样，描述里写的触发条件要跟着调一调。比如一个工具里你常说“检查一下”，另一个工具里你常说“帮我看一下”，描述里把两种说法都写上，触发才稳。
记住这条线：做法可以复用，工具的差别要单独处理。 把做法写干净，把差别放在适配层，Skill 才能既通用又不失真。
下一篇，我们讲多 Agent 并行：几个 Agent 同时干活，怎么不打架、不重复、不互相改错对方的东西。
