Claude 插件上架实战：从 GitHub 到目录审核

Claude 插件发布流程速览

发布 Claude 插件，可按以下顺序操作：

1. 确认用于提交的 Claude 账号已订阅 Pro、Max、Team 或 Enterprise。
2. 选择未来长期持有该目录条目的组织。
3. 准备插件包，其中应包含 .claude-plugin/plugin.json、README 和许可证。
4. 先在本地测试插件文件夹，再将其放入已连接 GitHub 账号有推送权限的仓库。
5. 打开开发者门户，选择 Plugin bundle，填写仓库、可选的插件路径以及要跟踪的分支或标签，然后运行 Validate。
6. 填完数据处理、合规、联系方式和更新设置，选择 Submit for review。
7. 如果插件会调用你运营的远程 MCP 服务器，还要为该服务器另建一个 MCP connector 提交项。

只要满足 Anthropic 对 GitHub 访问和源码上传的要求，仓库在验证和审核期间可以保持私有；但插件正式上线前，仓库必须公开。

进门户前，先确定要提交哪类条目

插件和连接器彼此相关，却不能互相替代。可以把插件理解成一套装盒交付的操作手册，把远程 MCP 服务器理解成背后持续值守的服务台：前者教 Claude 如何执行工作流，后者让 Claude 实时访问你的产品或数据。

Skill 并不是第三种提交类型，而应放进 Plugin bundle。如果插件包引用了你托管的 MCP 服务器，应由同一个 Claude 组织提交这两项产品，并让它们指向同一个服务器 URL。这样门户才能关联两个条目，也能避免用户看到重复的工具集。

先决定目录条目归谁所有

组织选择是一项长期产品决策，不是普通的后台设置。对于 Plugin bundle，最先提交某个仓库文件夹的组织将持有该目录条目；第二个组织不能再次提交同一个仓库和文件夹。

账号规则很清楚：

• 使用 Pro 或 Max 时，由账号本人提交。
• 使用 Team 或 Enterprise 时，Owner 可以提交。
• 在 Enterprise 中，Owner 可以通过自定义角色授予 Directory 权限。
• 在该 Claude 组织内连接的 GitHub 账号，必须拥有仓库推送权限。

如果插件由代理公司开发，但公开身份应归客户所有，就应让客户的组织发起提交。事后移交仓库，并不等于移交目录条目。

上架需要多少成本

Anthropic 的公开说明没有列出单独的目录上架费，但 Free 账号不能提交。因此，进入门户的最低现金门槛，就是开通所需的付费账号。

• 从未订阅过付费套餐的独立开发者，可以按月购买 Pro，一个月为 $20；也可以年付 $200，折合每月 $17。
• Team 最少从两人起。按月付费时，两个 Standard 席位合计 $50；按年付费则折合每月 $40。
• Max 起价为每月 $100，但仅为提交插件并不需要 Max。

真正更高的成本是发布准备。托管型产品需要准备两个提交项：一个 Plugin bundle，一个 MCP connector。插件还需要稳定的 manifest、不少于 40 个非代码单词的 README、许可证、数据处理说明、审核联系人，以及能够转为公开状态的仓库。新门户把验证、安全扫描结果、审核状态、发布、更新和使用数据集中在同一处，降低了协调成本，但并没有省掉这些工作。

准备可提交目录的 Claude 插件包

一个最精简但足以提交的插件包，应采用以下结构：

your-plugin/
  .claude-plugin/plugin.json
  skills/your-workflow/SKILL.md
  README.md
  LICENSE

Manifest 中需要有永久固定的小写 name、面向用户的 displayName、version、信息明确的 description、作者，以及许可证声明或单独的许可证文件。永久名称要谨慎确定：displayName 可以修改，但 manifest 中的名称就是插件的身份标识。

README 不只是仓库里的例行文档。目录会把它用作条目介绍；如果 README 中非代码内容少于 40 个单词，验证就会阻止提交。请说明插件的用途、使用方法，以及它会发送哪些数据。任何真实凭据都不能放进仓库。

如果插件包引用了远程服务器，请把 HTTPS 端点写进 .mcp.json，不要把 API key 放进去。每一位安装者都会收到插件文件。

本地测试之后，还要在门户重新验证

在接入 GitHub 之前，可以先用本地验证发现格式错误的插件文件：

claude plugin validate ./your-plugin
claude --plugin-dir ./your-plugin

第一条命令检查文件语法和 schema。第二条命令会启动一个加载了该工作文件夹的 Claude Code 会话，便于实际运行其中的 skill 和 command。本地验证不能替代门户里的 Validate 按钮；门户还会检查目录规范、仓库布局、名称冲突、文件策略及其他提交规则。

本次演示创建了一个小型 release-note-builder 插件，其中包含一个 skill 和三个合成 issue 文件，分别对应新增审计日志 CSV 导出、分页改进和重复邮件修复。Claude Code 2.1.283 返回 Validation passed，退出代码为 0，且没有 error 或 warning。

随后，我们通过 claude --plugin-dir 加载该文件夹，使用测试数据运行。由于这台机器没有已认证的 Claude 会话，请求在模型调用前停在 Not logged in · Please run /login，因此没有观察到生成的 release note。这个边界很重要：文件夹验证可以在本地完成，但行为测试需要经过认证的模型访问。更完整的行为测试流程，请参阅单独的 Claude Code 插件评测指南。

填写 Claude 插件提交信息

公开文档所述的门户流程，可以归纳为六个实际阶段。

1. Source

以 URL 或 owner/repo 格式填写 GitHub 仓库。如果插件不在仓库根目录，还要补充插件路径。为后续版本选择一个分支或标签；如果留空，系统将跟踪默认分支。然后选择 Validate。

每次验证只读取一个 commit。推送修复后，要选择 Re-validate，让报告读取新的 commit。

2. Listing details

门户会根据 plugin.json 和 README 生成目录条目。如果名称、描述或说明有误，请修改仓库文件并重新验证。这种机制很有价值：对外承诺与实际发布的插件包会始终保存在同一次 release 中。

3. Data handling

如实回答插件是否会读取或存储个人数据、是否会向已声明连接器之外的任何位置发送数据、是否保留数据，以及是否面向 18 岁以下人群。不要把这些内容当作随手填写的表单，它们属于产品承诺的一部分。

4. Compliance and contact

提供一个 Anthropic 可用于审核联络的邮箱，再完成四项必需确认。门户可能会退回某个版本，并附上问题或修改要求，因此务必使用有人实际查看的收件箱。

5. Updates

在默认的 GitHub push webhook 与仅定时检查之间二选一。两种方式都能让目录监控指定的分支或标签；配置 webhook 需要仓库管理员权限。

6. Review and submit

确认所有信息，然后选择 Submit for review。同一个组织在 24 小时内最多创建 10 个提交，草稿和已撤回的提交也会计入。需要继续已有草稿时，不要重复新建提交。

远程 MCP 服务器需要单独提交

如果 Claude 插件会调用你运营的远程 MCP 服务器，请返回 Submit new 并选择 MCP connector。连接器流程要求提供更多运营细节，因为 Anthropic 要收录的是一项在线服务，而不是一个文件夹。

请提前准备服务器 URL、文档与隐私政策 URL、图标、审核人员测试凭据，以及所有 MCP App 轮播图。文档中的完整流程包括连接、已同步工具、公开条目、使用场景、公司信息、身份验证、数据处理、测试说明、合规和最终审核。

公开条目字段包括：不超过 100 个字符的服务器名称、不超过 200 个字符的单行描述、不超过 2,000 个字符的详细描述、一至五个分类，以及文档、隐私、支持、图标和永久 URL slug。如果产品必须登录，审核人员还需要一个已经填充数据的测试账号。不能因为 health endpoint 有响应，就宣称连接器已经就绪；应先通过 MCP Inspector 或 Claude 中的 custom connector 逐一运行所有工具。

把审核状态当成行动队列

官方没有承诺固定的审核时长。真正有用的问题不是“审核要多久”，而是“下一步该谁行动”。

Approved 不代表已经可以安装，Published 才代表真正上线。默认设置下，即使版本已经通过，也可能仍需 Anthropic 审核人员执行发布。部分插件之后可以配置为让通过检查的更新自动发布，但被暂缓的版本依然要继续等待。

第一次上线前就规划好更新方式

发布后，可以合并到已跟踪的分支，或移动已跟踪的标签。目录会读取新的 commit，完成验证和安全扫描，再把它显示为另一个版本。每次 release 都要提高 plugin.json 中的 version。

更新失败或被暂缓，并不会让正常工作的目录条目下线。在替代版本正式上线前，目录会继续提供最后一个已发布版本。因此，这条分支不仅是源码存放处，也是一条 release feed。

之后，Usage 标签页会闭合反馈回路。你可以在最长 90 天的选定时间段内查看安装量、活跃账号、留存率、版本占比、组件使用情况、加载错误、MCP 调用与延迟、条目浏览量、安装点击量和实际安装量。数据每天按 UTC 更新一次，并可导出为 CSV。在门户记录到真实安装之前，不要承诺任何安装数字。

最适合使用该门户的六类团队

1. 拥有远程 MCP 产品的 SaaS 团队

产品团队把在线服务器作为 connector 提交，再围绕它的工作流封装一个 skill，作为插件发布。客户既能获得工具访问能力，也能拿到让工具真正发挥作用的操作说明。团队则可从 connector 侧观察服务器健康状态和工具使用情况，从插件侧查看安装量及组件使用情况。

2. 工作流软件公司

费用、招聘、客服或销售平台，可以把最成熟的操作流程做成 skill，再与产品 connector 配套。真正的收益是提高采用质量：用户添加的是一套工作流，而不是一袋没有说明的 API 方法。

3. 开源插件维护者

维护者可以继续公开代码、跟踪 release 分支，并把门户作为稳定的目录条目和更新渠道。修复新 commit 期间，最后一个通过检查的版本仍然可用，因此不必要求每次仓库 push 都立即达到可交付状态。

4. 为客户交付插件的代理公司

代理公司可以开发并测试插件文件夹；但如果目录条目必须归客户所有，就应由客户组织提交。这样交接会更清晰：仓库控制权、目录归属、支持联系人和分析数据都会交到买方手中，而不是留在承包方。

5. 企业平台团队

Enterprise Owner 可以只向指定成员授予 Directory 权限，无需共享范围更大的 Owner 角色。这样既能把发布工作与一般组织管理分开，又能让目录条目留在公司组织内。

6. 希望走出终端的 Claude Code 工具开发者

Command 或 skill 可以进入更广泛的目录，但开发者必须先核对各界面的支持范围。Skill 可在 chat、Cowork 和 Claude Code 中运行；agent 与 hook 无法在 chat 中运行，本地 MCP 服务器也不能在 chat 中运行，而 LSP 服务器仍仅支持 Claude Code。这样可以避免目录条目承诺所有界面体验一致，实际插件包却做不到。

围绕门户值得开发的三款产品

1. Plugin Release Gate：机会最大

开发一项 GitHub check，在 release 分支进入门户前先检查插件。它可以运行本地验证，确认 README 和许可证是否齐全，标出不受支持的组件组合，对比 manifest 版本，并生成目录就绪报告。

需求已经显现：claude code plugins 在美国每月约有 5,400 次搜索，带有商业意图，CPC 为 $6.22。最小可售版本可以是一款 GitHub App，配套网页报告和仓库 badge。限制同样需要讲清楚：它不能如实承诺一定通过门户审核，因为 Anthropic 的目录检查和人工审核超出了本地命令的能力范围。它的价值是减少本可避免的失败，而不是保证获批。

2. Directory Listing Optimizer

开发一个报告层，导入门户导出的 CSV，把浏览量、安装点击量、安装量、发现来源、版本和组件使用情况，转化为 release 与目录文案优化建议。目标客户是已有足够流量、能够从每日数据中获得价值的插件发布者。

claude plugins 在美国每月约有 8,100 次搜索，同样带有商业意图，CPC 为 $9.05。MVP 需要支持 CSV 上传、漏斗计算、版本对比和每周行动清单。它的短板是冷启动：在插件发布并产生真实使用前，没有任何专有数据可供分析；而且它依赖导出文件，并非文档化的 analytics API。

3. Cross-Surface Plugin Auditor

开发一款静态扫描器，准确告诉团队：同一个插件文件夹在 Chat、Cowork 和 Claude Code 中分别会加载哪些内容。它应标出顶层 bin/ 目录、对本地 MCP 的依赖、chat 会忽略的 agent 和 hook，以及仅支持 Claude Code 的 LSP，并生成测试矩阵。

claude-plugins marketplace 在美国每月约有 1,900 次搜索，难度为 16，并带有商业意图。MVP 可以是一个以 Anthropic 支持矩阵为依据的仓库扫描器。它的难点是维护：平台支持范围会变化，而且只做终端工具的开发者可能并不在意跨界面兼容性。

Plugin Release Gate 是最值得投入的方向，因为每个版本都会用到它，而不只是首次上架。它也是对门户的补充，而不是试图替代门户。

这个门户解决不了什么

它不能让薄弱的插件突然变得有用。验证可以证明文件格式正确并符合策略，却无法证明某个 skill 能改善结果；它也无法保证组件在每个 Claude 应用中的行为完全一致。它不会提供固定审核时长，不能按需授予 Verified 标识，也不会在上线当天自动带来安装用户。

对于托管型 MCP 产品，它同样不会把所有内容压缩为一个条目。单独提交 connector 是有意为之，因为服务器的身份验证、健康状态、工具和策略都需要独立的运营记录。

统一发现体验仍会在 9 月 25 日发布后的数周内逐步上线。现阶段应以已有文档明确支持的界面为准；更广泛的发现能力是即将到来的分发渠道，而不是现在就能承诺的覆盖范围。

周一上班后，先做什么

先确定应由哪个 Claude 组织长期持有目录条目。挑选一个真实工作流做成 Plugin bundle，为它设置稳定的 manifest 名称，准备实用的 README 和许可证，然后运行本地验证。如果它会调用你托管的 MCP 服务器，就同步准备 connector 提交。在归属决定和仓库路径最终确定之前，不要打开门户开始提交。

如果你希望把插件及其生产环境 connector 打造成一套可靠的发布系统，请参阅 AI 生产系统。