plugin-kit-ai

Build a plugin once. Ship it to multiple AI agents from one repo. plugin-kit-ai is the home for our first-party plugin lineup and the open-source toolkit behind it.

One repo
Clear workflow
Open Source

A clean path from one plugin repo to many agents

Plain-language positioning, honest boundaries, and a workflow that stays manageable as the product grows.

One repo instead of scattered setup

Keep one plugin repo as the source of truth instead of copying the same logic into separate agent-specific folders.

Start with one strong path, add more later

Start by building the plugin for the one agent you need right now, then expand to more supported agents when your product actually needs it.

Validate before handoff

Use a repeatable generate and validate flow before another teammate, CI job, or end user touches the plugin.

Clear support boundary

The main paths are stable today. A few advanced surfaces are still clearly labeled beta, so teams know exactly what they can ship with confidence.

Install plugins across agents

Use one install path to land the same plugin in Claude, Codex, Gemini, OpenCode, Cursor, and other supported targets.

Update, repair, and remove safely

Keep managed installs current, repair drift when a target falls out of sync, and remove plugins cleanly when you no longer need them.

Our first plugins start here

Browse the real first-party catalog for online services and local tools. If the product value lives in your own runtime code, use the advanced custom-logic path instead.

View all

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

Get started

Pick an install path, open the docs, and start from one clean plugin repo.

Latest release · v1.2.2 · May 7, 2026

Fastest start

This is the fastest path to a real plugin install or a validated repo.

Choose how to run plugin-kit-ai

Run plugin-kit-ai without a permanent install when you want the fastest first plugin add.

01

Run plugin-kit-ai your way

Command
npx plugin-kit-ai@latest version

Fastest path when you want a one-command plugin install first.

02

Try a real plugin now

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

The first command is the safe single-target path. The second installs every supported output for that plugin.

03

Build your own plugin repo

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

Once the install path feels right, start from the template that matches the job.

04

Generate and validate before handoff

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

Use generate plus strict validation before CI, teammate handoff, or release.

Support snapshot

Real support depth today, based on the current support policy and target matrix.

Claude plugin package

Production-ready stable subset

Production-ready for the stable default hook subset. Settings and manifest support are solid; some wider Claude package surfaces still stay beta.

Codex runtime and package lanes

Production-ready

The Codex notify runtime lane and the official Codex package lane are both production-ready today.

Gemini extension lane

Production-ready

Gemini extension packaging is production-ready, and the Go runtime lane is production-ready for the current stable 9-hook contract.

OpenCode workspace-config lane

Packaging-only target

Repo-local config, MCP, skills, commands, agents, themes, and plugin refs are supported, but this is still a workspace-config target, not a production-ready runtime lane.

Cursor workspace-config lane

Packaging-only target

Project rules and MCP config are covered, while root CLAUDE.md and AGENTS.md stay reserved for plugin boundary docs; Cursor remains a strict workspace-config lane.

Read the support boundary

Why it works

Not a fight against competitors. Just a practical comparison against the three ways plugin teams usually create unnecessary drift.

Workflow
plugin-kit-ai
Manual setup
Duplicated configs
One-off scripts
One repo for many agent outputs
One source of truth
New setup per agent
Possible, but drifts fast
Usually one local flow only
Validation before handoff
Built around validate --strict
Depends on human review
Same check repeated everywhere
Easy to miss edge cases
Clear stable vs beta boundary
Documented and explicit
Usually tribal knowledge
Ambiguity gets copied too
No shared contract
Add outputs later without starting over
Grow from the same repo
Possible, but rework-heavy
Every new output starts from scratch
Usually a rewrite
Clear install and release channels
Docs, releases, and install paths line up
You assemble the flow yourself
Possible, but repeated work
Mostly local and ad hoc
Team-friendly onboarding
Shared workflow and examples
Lives in people and chat
More files, same confusion
Hard to hand off cleanly

Got questions? We've got answers

The practical version: what this solves, who it is for, and which page to open first.

Start here

Need a clearer next step?

Most people only need three pages: quickstart, the Python path if that is your stack, and the support boundary before promising too much.