ARTICLE · 1193849
Claude Code 插件装之前,先看官方目录怎么把它审一遍
Claude Code 插件 · 市场清单 · SHA 锁定 · 审核流水线 · 官方目录 ——
anthropics/claude-plugins-official（Star 数 38976）是 Anthropic 官方维护的 Claude Code 插件目录。
它不是某个具体功能插件，而是一份被 CI 守着的数据：.claude-plugin/marketplace.json
登记了 315 条插件条目，仓库里另有 40 个内部插件与 14 个内嵌的第三方插件。
安装入口统一为 /plugin install <插件名>@claude-plugins-official。
装插件，等于放权
Claude Code 插件不是一段只读文档。一个插件可以在 .mcp.json 里挂上 MCP server，
可以用 hooks 监听 PreToolUse、PostToolUse、Stop，在你每次调用工具前后执行脚本，
还能注册命令、子代理与技能。这些都跑在开发者自己的机器上：能读文件、能发网络请求、能执行 shell。
三个具体的麻烦会同时出现：
• 描述与行为的落差：一个说「帮你整理提交信息」的插件，可能在读 ~/.aws/credentials。
政策审查文档专门把「跨服务取凭证」列成红旗——凭证属于哪个服务，却被发往另一个服务。
• 上游一直在动：从 git 装插件等于把整个仓库 clone 到本地。 若只跟分支不锁 commit，上游一次 force-push 就能把已审过的代码换掉。
• 名字不能改：插件是以 slug 装在用户机器上的，改名会让老用户直接撞上 plugin-not-found。
受影响的是三类人：装了插件的个人开发者，风险自负； 要给团队定工具清单的平台与安全工程师，得说清「为什么这个可以装」； 以及想把插件分发出去的作者，需要一个可信的入口。
三条上手路径
路径一：装一个插件。 最短流程只有一条命令，或在 /plugin > Discover 里浏览挑选。
/plugin install code-review@claude-plugins-official
装完能力会以 <插件名>:<名称> 的形式出现：code-review 提供一轮针对 PR 的审查命令，
feature-dev 铺开一条「探索 -> 设计 -> 审查」的 agent 流程，hookify 则把 hook 配置交给用户自己写。
输入是插件名加市场名，动作是一次安装，结果是命令与子代理出现在当前会话里。
样例一：作者提交一个技能包（skill bundle）。
如果你的仓库里已经有一堆 SKILL.md，但不想再写一份 plugin.json，
可以在市场条目里声明 strict: false 和一个显式的 skills 数组：
{
"name": "example-bundle",
"source": { "source": "git-subdir", "url": "https://github.com/example-org/sdk.git",
"path": "packages/agent-skills", "ref": "main", "sha": "<commit sha>" },
"strict": false,
"skills": ["./skill-a", "./skill-b"]
}
每个路径指向一个含 SKILL.md 的目录，注册为 <插件名>:<技能名>。
路径可以比一层更深，方便你只暴露多个子目录里的一个子集，而不是把整个仓库摊开。
样例二：平台团队内嵌自有插件。
条目的 source 允许直接写仓库内相对路径（形如 ./plugins/code-review），
于是内部插件可以与外部插件共用同一份清单、同一套流水线，不必另建发布渠道。
样例三：变更与改名的正确姿势。
条目里的 name 是不可变 slug，改展示文案要改 displayName；
真的必须改名，就写进顶层 renames 映射，加载器会在用户下次同步时把旧 slug 透明改写。
两个常见误区值得提前避开：
• 插件从 git 安装时会把整个仓库落到磁盘。
.claude/、scripts/、tests/ 里没被加载的代码一样会被下载，
所以审核范围也是整个交付物，而不只是被加载的那部分。
• 不要以为「没有 hook」就等于安全。命令、子代理、MCP 配置与技能文本都能引导模型行为。
数据加流水线当门禁
仓库分三层：.claude-plugin/marketplace.json 是清单，
plugins/ 与 external_plugins/ 是内嵌负载，.github/ 是九条工作流组成的守门流程。
清单里 315 条目的来源相当混杂——164 条指向远端仓库、98 条走 git-subdir 子目录、
其余 53 条是仓库内相对路径，覆盖开发、生产力、数据库、监控、安全等分类。
一条外部条目的生命周期大致是这样：
• validate-plugins 调用共享 action 校验清单不变式，SHA 锁定属硬错误；
validate-licenses 要求内部插件都带 Apache 2.0 许可，claude-security 是已记录在案的例外。
• scan-plugins 让 Claude 按 .github/policy/prompt.md 逐文件读完整负载，
包括隐藏目录；再按 schema 输出结构化判定：是否通过、注册了哪些 hook、
是否联网、是否有未披露遥测、描述是否与行为相符。
判定按「插件加 SHA」缓存，缓存键还包含政策内容哈希——政策一改全部失效，TTL 为 30 天。
• bump-plugin-shas 每晚 07:23 UTC 扫描上游已越过锁定 SHA 的条目，在新 SHA 上先校验再更新，
一个插件一个 PR（分支 bump/<slug>），失败互不牵连。
由于这些 PR 由默认令牌创建、不触发 pull_request 事件，工作流反过来对每个分支
手动 dispatch 扫描、MCP 检查、校验三项必需检查。单次上限 60 个，
bump-tracking.json 里的条目则改为跟随最新 release tag 而非 HEAD。
• revert-failed-bumps 在扫描失败时把出问题的条目从 bump PR 里摘掉，一个坏上游不会卡住其余更新。
• external-pr-scope-guard 对非成员 PR 只允许「新增」，且新增条目的来源仓库
必须已经在支撑本目录里的一个在线插件。
新意集中在三处。
其一，把审核定义成对完整交付物的政策审查，而不是靠信任或人工背签。 判定项里专门有「描述是否与行为相符」与「是否未披露遥测」： 非恶意但越权的插件同样会被拒。这是对「插件只是个小工具」这一直觉的修正—— 一个插件可以不恶意，却依然超额收集它声称用途之外的数据。
其二，让昂贵的审核结果可缓存、可复用。 逐文件让模型读一遍成本不低，但「插件加 SHA」这个二元组让同一份代码只审一次； 配合每晚只更新真正变动的条目，成本被压进可接受区间。 政策变更时宁可全部重审，这一点是刻意选择。
其三，把供应链的「锁版本」与「别过期」同时做到。 SHA 锁定堵住了 force-push 偷换代码，每晚自动 bump 又避免锁死后收不到上游修复； 每个插件独立 PR、签名提交、必需检查补齐，都是围绕「自动更新不能绕过门禁」设计的。
代价也很直白：九条工作流本身需要维护——validate-plugins 里成片的路径写法，
就是在补「路径过滤不匹配导致必需检查永远 Pending」这一类坑；
模型政策扫描要消耗额度，缓存 TTL 与每晚上限都是为了控成本而设的阀门。
把流水线变成分发方式
最近可以落地的场景是企业内部市场。把内部插件 vendored 进一台自己的目录仓库， 照搬「清单 + 政策扫描 + 每晚 bump + 独立 PR」四件套， 安全团队审的是政策与脚本，而不再需要每次人工通读代码。
第二个场景是把 Agent 能力分发给外部用户。任何要把技能与 hook 交付到别人机器上的团队， 都要面对同样三件事：锁定 SHA、声明交付物边界、保住不可变 slug。 这三件事做齐了，「安装即授权」才有可核查的依据。
往更远看，浏览器扩展、编辑器插件、MCP server 目录都在同一个问题上打转。 这份仓库给出的答案，是把授权边界写进可机检的清单，再用 CI 持续复核它。 它不判断插件是否好用，但它把「插件是否只做它说的事」变成了一个能自动回答的问题。
