前些天看到推上有人发帖问：你们都是怎么管理 Skills 的，怎么在各个工具间同步的？
我太能理解了，就拿 Claude Code、Codex、Gemini Cli 这仨来说吧，Claude Code 在 .claude/skills，Codex 在 .codex/skills，Gemini Cli 在 .gemini/skills。
更别说再加上其他工具里，就比如 OpenCode 最开始连子目录都不叫 skills，而是 skill，后来才改的。
如果你在不同的工具使用过相同的 Skill ，大概率经历过这种痛苦。
刚开始 Skill 用的少，写一份直接在各个工具间复制，但是只要一改，就得改好几个地方。所以，后来一些常用的就用软连接的方式，只存一份就好。
现在我在一个固定的目录中统一存放我自己写的 Skill，然后用项目级的方式先进行调试，调试一般用 Gemini Cli 或 Antigravity。最终要在好几个地方建立软链接，好处就是一次建立好，后面再改动就省事了。
软链接虽然能解决一些问题。比如用 npx 方式安装的Skill，就可以自动在选择的工具中建立软链接，但是毕竟不是官方标准，终究治标不治本。
但是好消息来了，工具开发商也发现了这个问题。
2月3日，Codex 发推，向代理构建者发出公开呼吁：让我们从 .Agents/skills 读取代理技能，这样人们就不必为每个代理管理单独的文件夹了。
消息一发出，多家工具厂商开始响应支持，Gemini Cli 表示已经合并代码，将于下周发布。
除此之外，还有多家厂商也已支持，包括但不限于以下表格中的厂商。颇有一些热血的感觉。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
但是，很遗憾的时，一直到现在，Skill 标准的发起者 Claude Code， 还没有任何回应。
之所以各家反应这么快，那是因为大家都被这个问题烦够了。
技能碎片化不是某一家的问题，是整个生态的问题。用户在哪个工具上积累的技能，换个工具就带不走。这对工具厂商来说也不是什么好事，用户怕迁移成本，反而不敢尝试新工具。
统一标准对所有人都有好处。
所以，现在不用急着改什么了，就等着工具更新就好了。
如果想提前适配，把目录换成 .agents/skills，省得以后再折腾。
希望 Claude Code 也能适配这个标准，不要过于自大呀！
