Reddit r/ClaudeCode 用户 u/irekrog 于 2026 年 10 月 16 日发帖，发布了一个名为 skills-check-updates（简称 scu）的命令行工具，用来在更新 agent skills 之前，先看哪些技能在上游发生了变化。作者称，现有的 npx skills check 并不做检查，更新时还可能覆盖本地改动，scu 就是为此而写。项目托管在 GitHub 的 irekrog/skills-check-updates。
据作者在帖子中的说法，npx skills check 实际上是 update 的别名：它会直接重装技能，不提供预览，并且会覆盖用户在本地编辑过的内容。对于改过技能文件的用户来说，这意味着一次「检查」可能带来意外的覆盖。
作者介绍，scu 会读取 skills-lock.json，把每个技能与其 GitHub 来源逐一比较，并显示发生了哪些变化。不传 -u 参数时，scu 不会改动任何文件。
在评论区回复中，作者进一步说明，scu 以锁文件中的 computedHash 作为基线，分别比较「基线与本地」和「基线与上游」，由此给出三种状态：
加上 -u 后，遇到本地有改动的技能，默认会跳过，除非再加 --force。
有评论者建议，在 skills-lock.json 中多存一个字段，记录安装时对应的上游版本，以便分开比较两侧的改动，并在两边改到同一文件或同一代码块时让 -u 作为冲突停下。作者回复称，基线与两侧的区分已经具备，缺的是合并能力：此前只要本地有任何改动，整个更新就会被拦下，即使上游改的是另一个文件。作者也表示不打算把版本字段写进锁文件，理由是 skills CLI 每次 add 或 update 都会重写整个条目，额外字段在用户第一次运行 npx skills update 时就会丢失。
随后作者称，0.2.0 版已经发布这一改进：
-u 会在最近 20 个涉及该技能的提交中，匹配 computedHash 来找到基线提交，再用 git merge-file 逐文件合并；-u 以退出码 1 结束；--force 仍会覆盖本地内容。同一位评论者在 0.2.0 发布后补充了一个边界：如果 computedHash 在这 20 个提交里匹配不到，应把基线视为未知并跳过合并，而不是退回到别的做法（fail-closed）。其理由是较早安装的技能可能已经超出这个检查窗口。该评论者还建议用一个测试夹具覆盖这一情形，即匹配的基线位于 20 个以上涉及该技能的提交之前。作者在帖子里没有就这条建议再作回复。
以上内容来自作者的帖子、作者的评论及评论者 u/Tariq9977 的评论。
