PUBLIC DOCUMENTATION

plugin-kit-ai

Build your plugin once and easily export it to any AI agent, like Claude, Codex, or Gemini, without duplicating code.

One Repo, Many Supported Targets

• Start with one plugin repo, not a separate repo for each ecosystem.
• Add supported Claude, Codex, Gemini, and config/package outputs from that same repo as the product grows.
• Keep one validation workflow through render, validate, and CI.
• Avoid turning your setup into a pile of one-off templates and fragile glue scripts.

What To Know Right Away

• The repo and workflow stay unified across targets.
• Support depth depends on the target you add.
• Runtime plugins, package outputs, and workspace-managed config do not all carry the same guarantees.
• The safe promise is one repo with many supported outputs, not fake parity everywhere.

Start Fast

Install the CLI, pick Go, Node/TypeScript, or Python, and get the first working plugin repo quickly.

See Multi-Target Use Cases

See how one repo can expand into Claude, Codex, Gemini, bundle delivery, and workspace/config outputs.

Choose A Starter

Use a starter as the first step, not as the final limit of the product.

Check The Boundary

See which targets are strongest today and where support depth changes.

Start Here

• Start with go when you want the strongest production path and the fewest moving parts.
• Choose node --typescript when you want the main supported non-Go path.
• Choose python when the repo is intentionally Python-first.
• Choose Claude first only when Claude hooks are already the real product requirement.
• Use validate --strict as the readiness gate before handoff or CI.

Common Expansion Paths

• Start with a Codex runtime plugin, then add package/config outputs as needed.
• Start with Claude hooks, then keep the repo open for broader target coverage later.
• Start on Node or Python locally, then add portable bundle delivery when handoff matters.
• Keep deeper target decisions explicit instead of pretending every output behaves the same way.

What This Site Helps You Do

• start one plugin repo instead of splitting by ecosystem too early
• expand the same repo to multiple supported outputs over time
• keep one review and validation story as the repo grows
• understand where support is strongest and where it is narrower

Read In This Order

1. Quickstart

Start one repo on the strongest default path before you worry about expansion.

2. What You Can Build

See how the same repo can cover multiple supported outputs.

3. Choose A Starter

Pick the best entrypoint without treating it like a permanent boundary.

4. Support Boundary

Check where support depth changes before you promise the same thing everywhere.

If you are new, stop after those four pages. Everything else on this site is deeper reference.

Current Repo Baseline

• The current public baseline in this docs set is v1.0.6.
• That release made shared runtime-package delivery for Python and Node a real supported path instead of a partial story.
• Start there if you need the baseline for the current recommended path.

What You Can Do With It

• Build from one repo and expand into multiple supported outputs as the product grows.
• Start on the strongest Go path or use supported local Python and Node paths.
• Add Claude, Codex, Gemini, bundle, and workspace/config outputs from the same managed workflow.
• Reuse helper behavior through plugin-kit-ai-runtime when a shared runtime package fits better than copied helper files.
• Keep support boundaries explicit instead of assuming identical runtime parity across targets.

What This Site Covers

• Public guides for users and plugin authors.
• Generated API reference from the actual code and command tree.
• Public support and platform metadata.
• Public release history and support framing.
• Public policy pages for versioning, compatibility, and support expectations.

What Stays Out

• Internal release rehearsal material.
• Maintainer-only audit notes and operational checklists.
• Wrapper-package internals treated as API.