克隆仓库后先审查 Claude 技能权限

刚克隆的仓库，除了源码，还可能带着会被 Claude Code 加载的指令。作者检查了 2,427 个活跃公开仓库，想提醒开发者：启动前先读 .claude/skills/，因为项目技能可能预先授权工具、在加载时执行命令，还能覆盖你熟悉的同名命令。

这篇值得读的地方，是把「仓库里的 Markdown」和「本地执行权限」连了起来。不过，它统计的是能力和配置，并没有证明这些仓库正在实施攻击。

为什么一个 SKILL.md 就值得提前检查

作者指出了三个容易被忽略的机制。

首先是 allowed-tools。按照原文引用的文档，技能声明的工具，在使用该技能的轮次中可以免去权限提示；工作区信任状态不会限制这项授权。裸写 Bash 的范围很宽，Bash(git status *) 则只放行对应命令模式。Write、Edit、WebFetch 也需要检查。

其次是加载时执行。技能里的 ! 后接反引号，可以嵌入 shell 命令。例如原文的 !git status``，会在技能加载期间、Claude 读取技能内容之前执行。如果权限规则或技能的 allowed-tools 已经允许，就不会再询问。

第三是同名覆盖。在本地终端会话里，项目技能可以替代内置命令或随附技能。文档给出的例子是：项目的 code-review 技能会替换 /code-review。

你输入熟悉的命令，执行的可能是仓库作者定义的流程。

而且，不一定需要手动调用。作者检查的仓库中，98% 带有未设置 disable-model-invocation 的项目技能，Claude 可以在请求匹配描述时自行加载。这是机制允许的行为，不能据此推断它们实际都被调用过。

这些配置到底有多常见

先看最直观的命令重名。

153 个仓库在根目录拥有名为 review、code-review 或 security-review 的技能，约每 16 个仓库中有一个。把其他名称也算上，共有 399 个仓库存在重名，常见名称包括 verify、review、code-review、debug 和 plan。

这不等于伪装。作者抽查的 15 个审查技能，都是真实的代码审查流程。问题在于，审查标准来自仓库作者，其中一些还预先授权了 Bash。如果你希望获得独立检查，至少应该知道谁在定义检查规则。

加载命令也大多是普通读取操作：git 出现 144 次，bash 79 次，gh 36 次，还有 grep、find、cat、ls；5 处调用了 curl。这些名称只能提示检查方向，无法单凭工具名判断用途。

这组统计覆盖 41,142 个技能。样本的取得过程比较复杂：GitHub 搜索 filename:SKILL.md path:.claude/skills 报告 506,880 个匹配文件，但每次查询最多返回 1,000 条。作者拆成 58 个文件大小区间，抽取其中 41 个；最小的 22 个连续查询，此后隔一个区间查询一次，让各大小范围都有覆盖。

最终得到 31,272 个唯一文件，约占总量 6%，来自 16,304 个仓库。再按至少 5 星、October 7 以来有推送、非 fork、未归档筛选，得到 2,435 个仓库，实际读取了其中 2,427 个，并读取相关技能引用的脚本。

这里不能只看技能总数：一个仓库就有 3,132 个技能，仓库中位数却只有 7 个。因此作者同时按仓库、每仓库最多计入 10 个技能、全部技能三种口径报告，避免大型技能集合左右结论。

启动前检查什么，临时阅读又该怎么做

第一步是在仓库根目录执行 ls .claude/skills/，同时查找嵌套目录里的 .claude/skills/。优先读与你准备输入的命令同名的文件夹，再读 SKILL.md 的前置信息（frontmatter）。

第二步检查 allowed-tools，第三步搜索 ! 后接反引号的标记。前者说明提前放行什么，后者说明加载时准备执行什么。技能数量不如这两项和名称组合有用：几百个技能可能都很普通，一个名字熟悉、又授权裸 Bash 的技能就值得细读。

如果只是临时查看，原文给出的无交互运行方式是 claude -p --bare：不读取项目中的 hooks、skills、plugins 或 .mcp.json。另一个参数 --setting-sources user 会跳过项目设置文件和 .mcp.json。两者在原文中的保证范围不同，不能直接视为等价替代。

隐藏字符也在检查范围内。Claude Code 从 2.1.299（October 14）开始拒绝文件夹名称包含隐藏、方向改变或类似空白字符的技能，后续版本又修复了其他不可见字符问题。

作者发现的零宽字符大多无害，包括 emoji 连接符和嵌套代码块中的转义；一个藏词注释则属于安全测试示例。但有一个文件使用 Unicode tag characters 隐藏指令，同时预先授权了 Bash。命令本身无害，看起来是概念验证，却展示了普通阅读可能漏掉的内容。原文建议检查 U+E0000 到 U+E007F，没有公开仓库名称。

我的判断

我认同把项目技能纳入克隆后的检查范围。它既是团队工作流说明，也可能改变工具授权和命令解析，值得像依赖安装脚本一样提前阅读。

但这份材料是截至 2026 年 11 月 6 日的静态调查，不是攻击发生率统计。搜索按相关性返回，样本也不是随机抽取；至少 5 星且活跃的筛选条件，同样限制了代表性。作者没有安装或运行内容，模式规则既可能漏掉运行时拼接命令，也可能把文档引用算进去；同名覆盖也没有在所有会话类型中逐一验证。

它足以支持「启动前检查」，不足以支持「这些仓库很危险」。

原文没有比较逐次授权、容器隔离和预审技能的实际效果，也没有给出效率或事故率对照。便利与风险的取舍，仍属于机制分析和经验判断。

结尾还推荐了拥有 5,101 个技能、声称社区技能上架前经过审核的 AgentCraft 目录。作者 Adrian Vale 披露自己参与运营 AgentCraft。这层利益关系应当保留：目录审核可以作为参考，但原文没有提供足够细节证明其审核效果。

能拿来做什么

• 接手前端或 Node 仓库时，把技能检查放在首次启动 Claude Code 之前，先看根目录和嵌套目录，再优先阅读 review、verify、debug 等常用命令对应的技能。
• 团队维护技能时，检查是否确实需要裸 Bash，能限定命令模式就收窄范围；对加载时执行的命令写清用途，让接手的人容易核对。
• 只想无交互查看陌生项目时，可以按原文使用 claude -p --bare，并区分它与 --setting-sources user 的覆盖范围。
• 用 Claude Code 审查仓库时，先确认 /code-review 等命令实际对应哪个技能，再判断其中的审查规则是否符合你的目标。