Claude 社区插件市场：只读镜像与它背后的审查机器

核心判断

这个仓库几乎没有业务代码，主体是 .claude-plugin/marketplace.json 这一份约 1.5 MB 的 JSON 清单，外加四个 CI 工作流。它是一条单向分发管道的公开出口：社区插件经 Anthropic 内部审查流水线过滤后，同步到这个只读镜像，再通过 Claude Code 的 plugin 命令分发到终端。看懂这条管道的方向，和看懂管道上那几台自动机器——自动关 PR、自动校验、自动 bump、自动清扫所有者——就能解释这个仓库的绝大部分行为。

这个仓库是什么

anthropics/claude-plugins-community 是 Claude Cowork 和 Claude Code 的社区插件市场（Community Plugin Marketplace）镜像，2026 年 3 月 20 日建仓，Apache-2.0 许可，GitHub 语言统计标称 Python——真正的主角不是代码，而是那份 JSON 和 .github/ 下的自动化。4,464 Stars（2026-10-04 读数，发文时约 1.6k）。

三个关键定位：

1. 只读镜像：仓库不接受直接修改——外部 Pull Request 会被 close-external-prs.yml 自动关闭，变更只能从 Anthropic 内部审查流水线流入。
2. 单一数据源：核心就是 .claude-plugin/marketplace.json，它是 Claude Code 可安装社区插件的完整列表。
3. 节奏由变更驱动：README 说清单"每晚从内部审查流水线同步"，但 git 历史显示同步的颗粒度是"事件"而非"日历"——2026-08-24 到 10-01 之间有 37 天零提交，其间清单纹丝不动。没有变更就没有 commit，排队等待审查才是常态。

三条合起来决定读法：把它当成"官方背书的插件清单快照"，而不是一个可以自由贡献的代码仓库。

管道结构：从提交到安装

插件进入终端用户手里要走完这条单向管道：

开发者提交（claude.ai/directory/manage 门户）
    ↓
自动安全扫描
    ↓
人工审核准入
    ↓
内部流水线 → 事件驱动同步 → 本仓库 marketplace.json
    ↓
Claude Code / Claude Cowork 安装

方向不可逆：对本仓库提 PR 无法上架插件，提交入口只有一个——开发者门户 claude.ai/directory/manage（旧短链 clau.de/plugin-directory-submission 已 301 重定向到提交文档）。这个设计与 npm / PyPI 的"注册即发布"模式相反，把准入权完全收在官方一侧，代价是上架速度，换来的是清单里每个插件都经过统一的安全扫描。

关外部 PR 是一台机器，不是一句口号

README 里"直接提 PR 会被自动关闭"背后是 .github/workflows/close-external-prs.yml：PR 打开或重开时立即触发，查一次作者权限——有 admin 或 write 权限的放行（Anthropic 员工的内部 PR 因此能在列表里长期存活），github-actions[bot] 放行（自家 bump 自动化的新鲜度 PR 不能误伤），其余一律关闭并留下指引评论。

工作流源码里有一段值得抄进安全笔记的注释：豁免只匹配作者身份，绝不匹配分支名——因为这是 pull_request_target 工作流，在 fork PR 上以写令牌运行，任何人都能把 fork 分支命名为 bump/plugin-shas 来伪装成自动化，而 user.login 是认证身份，fork 控制不了。

三条通道：PR 列表里的真实分层

把箭头落到人身上，git 历史给出了三个可直接查证的样本。

员工通道：16 分钟走完。 2026-08-21，Anthropic Claude Code 团队成员 ThariqS（GitHub bio 自署 “Claude Code @anthropics”）开出 PR #2372「Add eli5 plugin」——工作流对有写权限的人放行，这个 PR 活了下来。分支上先 push 插件本体，随后在十几分钟里连改四处：调整 skill 提示词措辞、替换 HTML artifact 表述、删掉许可文件、保留 MIT 字段，像是校验指到哪就改到哪；18:53 创建，19:09 合并，全程 16 分钟。

外部修改：当天关闭。 8-27，一位外部用户提交「Update README.md」，工作流当天关闭，未合并——README 也轮不到外部改。

机械变更：有快车道。 外部账号 abibbs-ant（无姓名无公司署名的普通用户）开的 bump PR #2373「bump(qodo): 5c630679 → 357492ca」却被合并了，squash 保留了他的作者署名。对照之下分层清晰：纯机械的 SHA 更新走快车道，内容性变更必须走官方流水线——同一个 abibbs-ant 修改 scandit-sdk 上游地址的内容 PR，8 月 25 日提交，十月初还在队列里。

这三条通道合起来才是管道的完整样子：员工通道即时，机械变更快车，内容变更排队，其余一律自动关闭。

为什么设计成这样

三个取舍决定了这个仓库的长相，也都体现在前文的结构里。

收权换审查。 npm / PyPI 允许任何人注册即发布，质量靠社区事后纠错；这里把提交、扫描、审核全部收进官方流水线，代价是上架要排队，换来每个插件在进清单前都过一遍统一安全扫描。对终端用户，这是"可安装即已审查"的保证。

镜像换单一事实源。 仓库只读、拒绝外部 PR，才保证 marketplace.json 只被内部流水线写入。若允许社区直接改清单，单一数据源就不存在了。代价是看插件实现通常不能在这里看，要顺着 source 去原始仓库——例外见下一节的"字符串引用"。

扁平换上线速度。 category 大量缺失（见下节），市场目前是名录而非分类目录。这是功能尚未补全的信号，也是"先把插件铺进来"的取舍。

这三组取舍的共同点：审查与一致性优先，为此接受功能上的不完整。判断这个仓库是否够用，就看你的需求落在哪一侧。

两千多个插件的结构

解析 marketplace.json 后的实际数据（发文时点取 08-24 快照 a727be1c，现今为 10-04 读数）：

五周净增 1 个插件——不是清单在收缩，而是审查流水线的吞吐量本来就这么低。选择插件时不必担心"清单更新太快跟不上"，真正该担心的是想上的东西还没排到。

source 钉住了 commit SHA

原文数据之外，还有一个容易被漏看的细节：1876 个 url 类型条目全部带 sha 字段，钉在具体 commit 上；401 个 git-subdir 类型附带 ref 和 path，其中 398 个同样带 sha，只有 3 个例外只钉分支、跟随上游浮动。清单不是"指向某个仓库"，而是"指向某个仓库在某个时刻的状态"。上游怎么折腾，镜像里的安装体验不变；bump 一个版本，就在 git 历史里留一次显式的 bump(名字): 旧SHA → 新SHA 记录（如 bump(qodo): 5c630679 → 357492ca）。对一份分发清单来说，这是可复现、可审计的底线设计。

字符串引用是唯一的例外

6 个插件的 source 是 './名字' 形式的相对路径——eli5、next-steps、quickdesign、testdino、tres-finance-plugin、cowork-plugin-management。它们的代码就放在这个仓库的根目录里，是"镜像不是源"原则的唯一例外：看这几个插件的实现，恰恰要回到这里。

其中藏着一个悬空引用：cowork-plugin-management 在清单里指向 ./cowork-plugin-management，但仓库里并没有这个目录——发文时如此，现在仍然如此。它大概率由内部管道特殊处理，镜像侧无从验证；列在这里只是提醒：单一事实源里也存在指不出去的条目。

大厂已经进场，分类还是半成品

36 个插件带 author 字段，是一串熟悉的行业名字：Google（alloydb）、Amazon Web Services（aws-agents、aws-core、aws-data-analytics、aws-startup-advisor）、CrowdStrike、Databricks、Grafana、Xsolla、Meticulous。官方供应商选择直接进清单，而不是让社区代投。

category 则依旧稀疏：2283 个里只有 158 个有分类，集中在 development（104）、productivity（19）、database（11）；数据本身也不干净——“Developer Tools” 这个首字母大写的分类混在小写行列里。这个市场目前是"扁平名录"而非"分类目录"，找插件主要靠搜索而非导航。

少数条目还带有镜像清单里罕见的高级字段：10 个带 strict，2 个带 mcpServers，2 个带 skills，2 个用 displayName。它们不改变清单的整体形状，但说明 schema 在向更复杂的方向演化。

另有一条 renames 映射（qodo-skills → qodo、wordpress-com → build-with-wordpress、auth0-sdks → auth0、twilio → twilio-developer-kit），保证历史插件改名后旧名称仍可解析——分发基础设施里少见但贴心的兼容层。

镜像里藏着的安全机器

这个仓库真正的工程含量在 .github/ 下。四个工作流、两个数据文件，合起来是一套持续运转的供给链安全机制：

两个数据文件值得单独说。

freeze-shas.txt 是"已知坏上游"名单。 文件自注：这是 2026-06-13 的时点快照，收录那些在新 SHA 上过不了 validate-plugins 的条目——上游丢了 manifest，或 bump 会暴露错误字段。冻结它们是为了"避免把 bump 推成红色 PR"；没有列入名单的失败 bump，由 revert-failed-bumps 循环兜底回退。上游修好后移出名单，条目恢复新鲜。钉 SHA 是常态，但钉死哪个 SHA、放开哪个，都有一本明白账。

owner-baseline.json 防的是"用户名易主"。 GitHub 账号可以改名、用户名可以转手，但账号 ID 永远稳定。这份账本把清单里每个 source 仓库的所有者 login 记录到首次登记时的 GitHub ID——一旦某个 login 解析到了不同的 ID，意味着这个用户名换了主人，它名下的所有条目在进一步 bump 之前都要重新审查。这是清单类分发系统里少见的纵深防御：供应链攻击不必攻破仓库，接管一个改名后的用户名就够了，而这套机制把这条路堵死了。

这套机器仍在加码。8 月 12 日一天之内：移除 10 个上游不可用的条目、冻结 productivity-pro 的 pin、引入"源可用性 / 所有者验证"门禁与定期清扫；一周后的 8 月 19 日，又加上了对自动执行型 MCP launcher 的确定性静态 pin 检查。管道不只往里进插件，也往外挤——上游消失的、易主的、校验不过的，都会被清出去。

如何使用

消费端（Claude Code）：

# 添加社区市场
claude plugin marketplace add anthropics/claude-plugins-community

# 安装任意插件
claude plugin install <plugin-name>@claude-community

Claude Cowork 用户则直接在 claude.com/plugins 图形界面安装，无需命令行。

提交端：在开发者门户 claude.ai/directory/manage 提交，走自动扫描与人工审核。官方文档明说审核时长不固定（“Review time isn’t fixed”），状态要到门户里查。不要给本仓库提 PR——会被自动关闭。

几条官方门槛值得在动手前知道：

• 必须有付费计划：Pro、Max、Team 或 Enterprise；免费账户不能提交。Team 计划须 Owner 操作，Enterprise 须 Owner 或被授予 Directory 权限的成员。
• 先到先得：官方原话是"第一个提交某个仓库文件夹的组织持有该 listing"——同一个插件目录，别人先交，你就不能再交。
• 仓库必须公开：插件包的 GitHub 仓库要在上线前设为 public。
• MCPB 桌面扩展不再接受；插件若引用远程 MCP 服务器，服务器还须单独作为 MCP connector 提交（默认以 Community 身份上架，Anthropic 审核后可升级为 Verified）。
• 一次提交覆盖所有渠道：上架后正常合并到被跟踪分支的每个 commit 会被自动拾取、扫描并发布，无需重复提交。发布后的 Usage 页提供安装量、版本分布和错误率遥测。

与另外两个官方插件仓库的分工

Anthropic 的插件体系有三个仓库，定位清晰不重叠：

• anthropics/claude-plugins-official（37,362★）：Anthropic 官方自维护的插件
• anthropics/claude-plugins-community（4,464★，本文）：社区提交、官方审查分发的镜像
• anthropics/knowledge-work-plugins（26,050★）：面向具体知识工作角色的插件集

Stars 均为 2026-10-04 读数。三个里 community 规模最小，但它是唯一有提交入口的——official 展示官方能力，knowledge-work 沉淀角色工作流，community 接住整个长尾。

适用边界与采用建议

• 它是镜像不是源：想看某个插件的实现，顺着条目里的 source 链接去原始仓库；只有 6 个字符串引用的例外住在本仓库。
• 它不承载插件质量评价：审查流水线筛的是安全与合规，不是好不好用，选型仍需自行判断。
• 提交时效以周计，且不承诺上限：外部 PR 有积压近六周的实例（8 月 25 日提交的 scandit-sdk PR，10 月初仍在队列里），官方口径是审核时长不固定。别把"次日可见"当预期。
• 清单的 git 历史是审计日志，不是进度条：提交后去门户查状态，不要盯着这个仓库的 commit 等自己的名字。

据此给出采用顺序：

• 只用现成插件、不提交新插件：执行一次 claude plugin marketplace add，之后按需 install，无需再关注这个仓库本身。
• 想发布自己的插件：确认付费计划与公开仓库，从开发者门户提交，接受以周计的排队，提交前先查同名目录是否已被他人占用。
• 做插件选型对比：把 marketplace.json 当作数据源自行解析统计，比逐个浏览插件页更高效——本文的结构数据就是这条路线的一个示例。
• 关心供应链安全：这个仓库的 .github/ 目录本身就是一份值得通读的参考实现——SHA 钉定、所有者基线、冻结名单、失败回退，四件套都齐了。

小结

claude-plugins-community 展示了一种克制的基础设施设计：单一 JSON 作为唯一事实源、单向管道保证审查不可绕过、rename 层维护向后兼容；而 SHA 钉定与所有者基线把"可安装"进一步升级为"可复现、可追责"。它同时也用五周净增 1 个插件的吞吐量提醒你：审查是有代价的。对 Claude 生态的开发者，它是提交插件的必经之路；对关注分发机制设计的人，它是"把市场做成数据文件、把安全做成工作流"的干净样本。