plugin-kit-ai

构建一个插件一次。从一个存储库将其发送给多个 AI 代理。 plugin-kit-ai 是我们第一方插件阵容及其背后的开源工具包的所在地。

一个仓库
清晰的工作流程
开源

从一个插件存储库到多个代理的干净路径

简单的语言定位、诚实的边界以及随着产品的发展而保持可管理的工作流程。

一个存储库而不是分散的设置

保留一个插件存储库作为事实来源,而不是将相同的逻辑复制到单独的特定于代理的文件夹中。

从一条强路径开始,稍后添加更多路径

首先为您现在需要的一个代理构建插件,然后在您的产品实际需要时扩展到更多受支持的代理。

移交前验证

在其他队友、CI 作业或最终用户接触插件之前,使用可重复的生成和验证流程。

诚实的稳定版与测试版边界

plugin-kit-ai 明确说明了什么是生产就绪型、什么是公开测试版以及您不应该在哪些方面承诺虚假平价。

在多个代理上安装插件

使用一条安装路径即可将同一个插件部署到 Claude、Codex、Gemini、OpenCode、Cursor 和其他受支持的目标。

安全地更新、修复和移除

让托管安装保持最新,在目标失去同步时修复漂移,并在不再需要时干净地移除插件。

我们的第一个插件从这里开始

浏览面向在线服务和本地工具的真实第一方插件目录。如果产品价值体现在你自己的运行时代码中,请改用高级 custom logic 路径。

查看全部

Build your own plugin

Create your own plugin

Pick the repo shape that matches the job, then open the guide that explains that path in more detail.

Connect an online service

Start with a hosted integration like Notion, Stripe, Cloudflare, or Vercel.

Command
plugin-kit-ai init my-plugin --template online-service
Open the job-first guide

Connect a local tool

Start with a repo-owned tool like Docker Hub, Chrome DevTools, or HubSpot Developer.

Command
plugin-kit-ai init my-plugin --template local-tool
Open the job-first guide

Build custom plugin logic

Advanced

Choose this when your code, hooks, or runtime behavior define the product.

Command
plugin-kit-ai init my-plugin --template custom-logic
Open the advanced guide

开始使用

选择一个安装路径,打开文档,然后从一个干净的插件存储库开始。

最新发布 · v1.1.2 · 2026年4月19日

最快开始方式

这是通往真实插件安装或已验证仓库的最快路径。

选择如何运行 plugin-kit-ai

当您想最快添加一个真实插件时,无需永久安装即可运行 plugin-kit-ai。

01

按你的方式运行 plugin-kit-ai

Command
npx plugin-kit-ai@latest version

当您首先想要一次性插件安装时,这是最快的路径。

02

现在就试一个真实插件

Command
npx plugin-kit-ai@latest add notion --target claudenpx plugin-kit-ai@latest add notion

第一条命令是安全的单目标路径。第二条会为该插件安装所有受支持的输出。

03

创建你自己的插件仓库

Command
npx plugin-kit-ai@latest init my-plugin --template online-servicecd my-plugin

当安装路径已经清晰后,再从与任务匹配的模板开始。

04

在移交前生成并验证

Command
npx plugin-kit-ai@latest generate .npx plugin-kit-ai@latest validate . --platform claude --strict

在 CI、交接给队友或发布之前使用 generate 和严格验证。

支持快照

今天的实际支持深度基于当前的支持政策和目标矩阵。

Claude 插件包

生产就绪的稳定子集

稳定的默认钩子子集已做好生产准备。设置和清单支持很可靠;一些更宽的 Claude 封装表面仍处于测试阶段。

Codex 运行时和包通道

生产就绪

Codex 通知运行时通道和官方 Codex 包通道现已投入生产。

Gemini 延伸车道

生产就绪

Gemini 扩展打包已做好生产准备,而 Go 运行时通道已为当​​前稳定的 9-hook 合约做好生产准备。

OpenCode 工作区配置通道

仅包装目标

支持存储库本地配置、MCP、技能、命令、代理、主题和插件引用,但这仍然是工作区配置目标,而不是生产就绪的运行时通道。

Cursor 工作区配置通道

仅包装目标

涵盖了项目规则和 MCP 配置,而根 CLAUDE.md 和 AGENTS.md 保留用于插件边界文档; Cursor 仍然是严格的工作区配置通道。

读取支撑边界

为什么它有效

不是与竞争对手的斗争。只是与插件团队通常造成不必要漂移的三种方式进行实际比较。

工作流程
plugin-kit-ai
手动设置
重复的配置
一次性脚本
多个代理输出的一个存储库
真理的来源之一
每个代理的新设置
有可能,但漂移得很快
通常只有一个本地流
移交前验证
围绕 validate --strict 构建
取决于人工审核
到处重复同样的检查
容易错过边缘情况
清晰的稳定版与测试版边界
有记录且明确
通常是部落知识
歧义也被复制
没有共享合同
稍后添加输出而无需重新开始
从同一个仓库增长
可能,但需要大量返工
每个新输出都从头开始
通常是重写
清晰的安装和发布渠道
文档、版本和安装路径对齐
您自己组装流程
可能,但重复工作
主要是本地和临时的
团队友好的入职培训
共享工作流程和示例
生活在人和聊天中
更多文件,同样的混乱
很难干净地交接

Got 问题?我们已经有了答案

实用版本:它解决了什么问题,它适用于谁,以及首先打开哪个页面。

从这里开始

需要更清晰的下一步吗?

大多数人只需要三页:快速入门、Python 路径(如果这是您的堆栈)以及在承诺太多之前的支持边界。