求更｜Vercel skills CLI v1.5.22 值得升级吗？三组对照验证嵌套发现、共享锁与 MiniMax

直接答案

如果你的 Skill 仓库有多层分类、同一 Skill 会装给多个 Agent，或者你准备接入 MiniMax Code，Vercel skills CLI v1.5.22 值得升级。我们用 v1.5.21 做了三组同环境对照：嵌套 Skill 发现从 1 个变成 2 个；只从 Codex 移除共享 Skill 后，锁记录从被清空变成继续保留；MiniMax Code 从“不支持的 Agent”变成成功安装。

推荐是有条件的：这三条已经本地通过，官方仓库的 740 项测试也通过；但 skills.sh / well-known 在线更新、自托管 GitHub host 和真实团队全局目录没有独立端到端复现。依赖这些路径的团队，升级前仍应备份 skills-lock.json，并在临时项目里跑一次 update/remove。

v1.5.22 到底改了什么

Vercel 在 2026 年 8 月 5 日发布 skills CLI v1.5.22。官方 changelog 包含十项变化，其中会直接改变用户行动的不是版本号本身，而是四类安装状态问题：

• 能发现 skills/<分类>/<Skill>/SKILL.md 以及更深一层分类里的 Skill；
• well-known 与 skills.sh pack 在 update 时能识别上游新增 Skill；
• 多个 Agent 共用一个 Skill 时，从其中一个 Agent 移除不应提前删除锁记录；
• 新增 minimax-code Agent 目标，安装目录为 .minimax/skills/。

另外还有 GitHub shorthand 标准化、自托管 GitHub host 保留、非交互 find 返回完整结果、local path 在锁文件中的可移植表示等修复。它们都值得关注，但这次没有把每一条都包装成本站独立实测。

实验环境与版本怎么固定

我们把官方 v1.5.22 tag 固定到 commit a4d243c3d4f86cdf9385dd1b6a0733f6937e70b5，对照 v1.5.21 commit 7cb7db64dc1201052dea305e508a2fc490f7e5e2。实验运行在 macOS 26.5.1 arm64、Node.js v24.14.0，所有 fixture 和安装目录都放在 /tmp/token-beggars-skills-v1522.* 下，没有写入用户的全局 Skill 目录。

两个测试 Skill 分别位于：

skills/core-skills/amazon-bedrock/SKILL.md
skills/specialized-skills/database-skills/amazon-dynamodb/SKILL.md

第二个路径比常见的 skills/<skill>/SKILL.md 多了两层分类，正好能观察旧版是否漏检。

对照一：多层分类下的 Skill 能不能被发现

同一个 fixture 分别执行：

npx --yes skills@1.5.21 add ./fixture --list
npx --yes skills@1.5.22 add ./fixture --list

v1.5.21 输出 Found 1 skill，只列出 amazon-bedrock；v1.5.22 输出 Found 2 skills，同时列出 amazon-bedrock 与 amazon-dynamodb。两条命令都正常退出。

这项修复对“仓库里明明有 Skill，CLI 却列不出来”的用户最直接。尤其是按产品线、云厂商、数据库继续分组的仓库，旧版可能不会报错，只会安静地漏掉更深层的 Skill。

对照二：多个 Agent 共用 Skill 时，锁记录会不会提前消失

我们把同一个 amazon-bedrock 同时安装给 Codex 和 Claude Code，然后只执行 Codex 侧的 remove。

npx --yes skills@VERSION add ../fixture --skill amazon-bedrock --agent codex --agent claude-code --yes
npx --yes skills@VERSION remove amazon-bedrock --agent codex --yes

两个版本的共享 Skill 目录和 Claude Code 链接都还存在，差异出现在状态记录：v1.5.21 的 skills-lock.json 已经没有任何 Skill key；v1.5.22 仍保留 amazon-bedrock。

这不是清理美学。磁盘上的 Skill 仍被另一个 Agent 使用，锁记录却提前消失，后续 list、update、恢复与来源追踪就可能失去依据。v1.5.22 把文件状态与锁状态重新对齐。

对照三：MiniMax Code 是否真的能作为安装目标

同一个本地 Skill 指定 --agent minimax-code：

• v1.5.21 报 Invalid agents: minimax-code，退出码 1；
• v1.5.22 安装成功，目标为 .minimax/skills/amazon-bedrock，退出码 0。

所以这不是 README 先写、CLI 还没接上的占位支持。至少在本地路径、指定单个 Skill、非交互安装这条路径上，MiniMax Code 已经能工作。

官方仓库测试能补充什么

我们在 v1.5.22 官方源码 checkout 上使用锁定依赖运行 TypeScript 检查与全量 Vitest：55 个测试文件、740 项测试全部通过。另跑了一组 6 文件、100 项定向测试，覆盖 nested discovery、well-known update、remove、update source、MiniMax Code 与 non-interactive find。

这些测试能说明 release commit 内部的回归套件是绿的，但不能替代真实外部系统。尤其是 skills.sh / well-known 更新，本次通过的是上游仓库测试，没有另起公网 registry 做独立网络实验。

哪些人应该现在升级

1. Skill 仓库按两层或更多分类组织，曾遇到列表漏项；
2. 同一 Skill 同时服务 Codex、Claude Code、Cursor 等多个 Agent；
3. 正在使用 skills.sh pack 或 well-known 来源，并依赖 update 获取新增 Skill；
4. 需要把 Skill 安装到 MiniMax Code；
5. 使用自托管 GitHub，希望更新时保留锁定 host。

如果你只安装单层目录下的本地 Skill，而且从不使用 update/remove，升级收益没有那么明显。不要仅因为“最新版”三个字改变稳定环境。

升级前后的最小检查清单

1. 复制当前 skills-lock.json；
2. 运行 npx skills@1.5.22 add <source> --list，核对 Skill 数量与名称；
3. 在临时项目执行一次 update，确认来源 URL 与 host 没漂移；
4. 对共享 Skill 只移除一个 Agent，再检查其他 Agent 链接和锁记录；
5. 比较升级前后 lock diff，不要只看“Done”；
6. 最后再把固定版本改成团队默认。

常见问题

v1.5.22 可以直接全局升级吗？

建议先在临时项目用 npx skills@1.5.22 跑 list、update 和 remove。全局目录里通常混有多个 Agent 和历史来源，正是锁状态错误影响最大的地方。

740 项测试通过，是否代表任意 Skill 都安全？

不代表。它验证的是 CLI 行为，不审计被安装 Skill 的内容。Skills CLI 自己也提醒：Skill 会以 Agent 的完整权限运行，安装前仍要检查来源和内容。

这次能证明 skills.sh 在线更新一定正常吗？

不能。well-known / skills.sh 更新路径通过了官方仓库测试，但本站没有搭建独立在线 registry 做端到端复现。我们把它列为值得继续验证的路径，而不是已经独立通过。

如果你正在用多 Agent、skills.sh pack 或自托管 GitHub，请带一次脱敏后的升级前后 lock diff 回来。我们最想确认的是：真实项目里更新后新增 Skill 是否出现、来源 host 是否保持、共享 Skill 的状态是否还能完整恢复。

— Token Beggars 编辑部

参考来源

• Vercel skills CLI repository at v1.5.22