Skill
One capability. A single SKILL.md the agent loads when it is relevant. The atom.
What is a plugin marketplace for AI coding agents?
A plugin marketplace is a Git repository that holds a catalog of installable plugins for AI coding agents, alongside the plugin content itself. The agent reads the catalog, lists what is available, and installs whatever the developer picks.
That is the whole idea. A marketplace is distribution infrastructure, not a store: nothing is sold, there is no central registry to publish to, and no account to create. The catalog says what exists and where to find it — the agent does the rest.
This page explains what goes inside a plugin, how the different agents consume a marketplace, and how to create one. If you already know all that and just want the tool, jump to the agkit quick start.
The problem
Copy-pasting prompts does not scale
Every serious user of an AI coding agent accumulates the same things: a prompt that enforces the team's test conventions, a slash command that opens a release checklist, a subagent that reviews migrations. They start life in one developer's config directory.
Then a teammate wants them. So the files get copy-pasted into a Slack thread, then into a Notion page, then into someone's dotfiles repo. Nobody knows which copy is current. When the convention changes, four copies drift apart, and the agent confidently applies the stale one.
A marketplace fixes the distribution problem the same way package managers did for libraries: one source of truth, versioned, installed by name. The catalog is committed to Git, so reviewing a change to a shared prompt becomes a pull request like any other.
Anatomy
What is inside a plugin?
A plugin is a versioned bundle with a manifest (plugin.json: name, version, description) and one or more capabilities. Most plugins ship exactly one — the bundle is the unit of distribution, not a container you are meant to fill.
| Capability | Lives in | What it does |
|---|---|---|
| Skill | skills/<name>/SKILL.md | Reference knowledge or a repeatable procedure the agent loads on demand, when its description matches the task. |
| Command | commands/<name>.md | A prompt shortcut the developer invokes explicitly, as /<name>. |
| Subagent | agents/<name>.md | A named specialist with its own role and instructions, that the main agent delegates to. |
| Hook | hooks/hooks.json | Deterministic automation on lifecycle events — run a formatter after every edit, for instance. Code, not a prompt: it always fires. |
| MCP server | .mcp.json | Bundles a Model Context Protocol server, giving the agent external tools. |
The distinction that trips people up most is skill versus command. A command is pulled — the developer types it. A skill is pushed — the agent decides to load it based on the description you wrote. Which is why a skill's description is the load-bearing part: it is what the agent reads to decide whether the skill is relevant at all.
Disambiguation
Skill, plugin, marketplace
These three terms get used interchangeably, and they are not the same thing. From smallest to largest:
Plugin
A versioned bundle of capabilities — skills, commands, subagents, hooks, MCP servers — with a manifest. The unit you install.
Marketplace
A catalog listing many plugins, so an agent can discover and install them. The unit you distribute.
You do not need a marketplace to share one plugin — a standalone plugin repository works, and any catalog can reference it remotely. A marketplace pays off when you maintain several plugins, want a single install flow for a team, or need updates to propagate across a set.
Consumption
How agents read a marketplace
Here is the part the ecosystem has not settled yet, and the reason building a marketplace is more annoying than it should be: there is no shared standard. Agents fall into three groups.
Some read a catalog natively. Claude Code and GitHub Copilot both read .claude-plugin/marketplace.json as it sits in your repository. A consumer runs /plugin marketplace add owner/repo, then /plugin install <name>@<marketplace>. Nothing to generate — push the repo and it installs.
Some need their own registry. OpenAI Codex and Cursor look for a different file, in a different place, in a different shape — .agents/plugins/marketplace.json for Codex, .cursor-plugin/ for Cursor. The plugin content is identical; only the index differs. So you commit a second (and third) registry describing the same plugins.
Some have no marketplace concept at all. Windsurf reads .windsurf/rules/ and .windsurf/workflows/; OpenCode reads .opencode/skills/ (and, helpfully, .claude/skills/). These are local directories in the developer's own project — not something they can subscribe to. For those agents, "installing" means copying files into the consumer's workspace, which is a genuinely different model from publishing a catalog.
The practical consequence: keep one canonical catalog and derive the rest from it. Maintaining three registries by hand is how they drift — and a drifted registry is worse than no registry, because it fails at install time, on someone else's machine.
Getting started
How to create a plugin marketplace
You can absolutely do it by hand: create .claude-plugin/marketplace.json, add a plugins/ directory, write a manifest per plugin, keep the catalog in sync as things change, and hand-maintain the per-agent registries. It is all plain JSON and Markdown — nothing is hidden from you.
agkit is a CLI that does that part for you. It scaffolds a push-ready repository, adds plugins from templates, derives the per-agent registries from the canonical catalog, and keeps everything reconciled as plugins come and go:
npx agkit init my-marketplace
cd my-marketplace
npx agkit add skill tdd-coach
npx agkit validate
git pushOnce pushed, anyone can install from the repository with their agent's own command. Distribution is a plain git push to any forge — GitHub, GitLab, Bitbucket, Gitea, or self-hosted.
FAQ
Common questions
Is a plugin marketplace the same as an app store?
No. Nothing is sold, reviewed or centrally hosted. A marketplace is a Git repository with a catalog file — closer to a Homebrew tap or an APT source than to an app store. There is no gatekeeper, and no publishing step beyond git push.
Where is a plugin marketplace hosted?
In a plain Git repository, on any forge — GitHub, GitLab, Bitbucket, Gitea or a self-hosted server. Agents fetch it over Git, so there is no registry to publish to and no account to create. On GitHub the owner/repo shorthand works; everywhere else the full git URL does.
Do I need a marketplace to share a single plugin?
No — a standalone plugin repository is enough, and any catalog can reference it remotely. A marketplace earns its keep when you maintain several plugins, want one install flow for a team, or need versioning across a set of them.
Can one marketplace serve several agents?
Yes, and that is the point of keeping a canonical catalog: the plugin content under plugins/ is shared, and each agent's index is derived from it. Claude Code and GitHub Copilot read the canonical catalog directly; Codex and Cursor install from a generated registry. Agents with no marketplace concept — Windsurf, OpenCode, Kiro — cannot subscribe to a catalog at all today.
How do teams get plugins automatically?
Agents that support it read an extraKnownMarketplaces block from a settings file committed to the project — .claude/settings.json for Claude Code, .github/copilot/settings.json for GitHub Copilot. Teammates get the marketplace as soon as they trust the repository, with nothing to run.