localskills.sh

嘿 PH 👋 我是 Matthew。

每个人都在为自己的编码智能体编写技能和规则，但几乎所有这些都死在了某个人的 dotfiles 里。localskills.sh 是一个解决这个问题的 registry。

只需发布一次技能，就能通过一条命令将其安装到 Claude Code、Cursor、Windsurf、Codex 或 Copilot 中。团队可以获得一个带有权限、SSO 和双向 GitHub 同步的私有 namespace。还有一个 MCP 服务器，这样你的智能体可以在任务中途自主拉取技能。

你会希望整个团队使用哪一个技能？

前面那个版本问题还有一个更隐蔽的变种，我觉得那才是真正让人头疼的。

版本漂移至少还能被察觉。两个人对一下笔记，就能发现版本不一致。而一个技能完全加载失败，或者加载了一个没人预期的版本，却不会产生任何信号。缺少依赖会抛出错误，但缺少一个技能，智能体只会无视那些本应约束它的规则来作答，而且回答看起来完全正常。我把自己智能体的规则放在一个全局文件里，旁边还堆了一堆技能。真正让我吃亏的那些运行，从来不是因为报错，而是因为磁盘上明明放着的规则，就是没能传给模型，而输出里也完全看不出来。

所以在权限和固定版本的讨论背后，真正的问题是：一次运行能否事后证明哪些技能被放进了它的上下文？安装和加载是两码事，而目前只有其中一个是可检查的。

我想要的会是一个部署前检查清单技能——那种枯燥到没人会持续更新的东西。不过我更想了解的是任务中途拉取这部分。如果一个技能携带了塑造智能体行为的规则，那么任何能发布到 namespace 的人，都可以不经代码审查就改变智能体的行为。发布是否受制于和 repo merge 一样的审查流程，还是仅仅由 namespace 权限控制？

“死在某个人的 dotfiles 里”这个说法完全正确——我在 .cursorrules 和 Cursor 规则文件上也见过同样的情况，只有写它们的资深工程师才知道。在推广这个之前，我想了解一件事：skills registry 默认是自托管，还是放在你们的云上？如果团队特有的约定最终被写进了技能定义里——比如内部 API 模式、数据处理规则——那信任模型就会因 registry 的部署位置而改变。

“死在某个人的 dotfiles 里”这个说法太对了，我见过的每个团队都有一位资深工程师写的优秀 cursor 规则文件，却没人知道它的存在。回答你的问题——可能是一个 PR 描述技能，它从实际的 diff 而非 commit messages 中提取信息，我们的 PR 描述总是与实际变更不同步。

关于通过 MCP 在任务中途拉取的问题——如果一个技能在 sprint 中途被更新，那么一个已经基于旧版本执行任务的智能体会被自动更新，还是会继续使用任务开始时拉取的那个版本？团队内的版本漂移似乎会悄悄造成最大的混乱，因为两个人的智能体可能在不同版本的技能上工作而浑然不觉。

希望安装时能对特定技能进行版本锁定，这样团队可以锁定一个已知稳定的构建版本，而不是总是拉取最新版。类似于 lockfile 或每个技能的 `--version` 参数，这样能让跨项目的共享智能体规则更可靠。