What problem are you trying to solve?
Cursor, Claude Code, and other coding agents already have plugins: a company keeps one git repo of domain bundles (iOS conventions, backend review, shared API standards), and each project enables the plugins that apply. Engineers do not copy skills into every repository. A new hire on iOS turns on shared + ios; a backend repo turns on shared + backend. Updates land in the marketplace once and flow to every consumer.
That is the useful unit of sharing inside a company — not a single SKILL.md, and not “install every skill we have.” A plugin is a named pack. A marketplace is the catalog of those packs, almost always a git repository with a small manifest.
eve does not have this layer. Skills are authored under agent/skills/ or installed by copying files into the agent. Extensions are excellent for shipping code (tools, connections, instruction fragments) as a versioned package. They are not a company skill library: they do not let an on-call agent enable infra and a coding agent enable ios from the same catalog, and they do not let that catalog move independently of an npm publish.
The result: organizations that already maintain a Cursor/Claude marketplace must re-implement the same idea for eve, or fork skills into each agent. eve would benefit from the same product: point an agent at a marketplace, enable plugins, and those skills become available like local ones.
Proposed solution
Give eve agents a plugin marketplace, in the same spirit as Cursor and Claude Code:
- A marketplace — a git repo that lists plugins (today:
.cursor-plugin/marketplace.json / .claude-plugin/marketplace.json). eve can use its own manifest (.eve-plugin/marketplace.json or similar) if that is cleaner. The catalog idea should stay the same so a company is not forced to maintain a third content repo.
- A plugin — a named bundle (e.g.
ios, backend, shared) whose skills live under skills/<name>/SKILL.md, following the Agent Skills layout those other tools already use.
- Per-agent enablement — each agent declares which marketplace it uses and which plugins are on. A specialist enables two plugins; a generalist enables more, or discovers a plugin when the task enters that domain. Not every skill in the company needs to be advertised on every session.
- On-demand skills — once a plugin is enabled, its skills behave like eve skills today: descriptions for routing, full body via
load_skill when relevant.
The authoring experience should feel like Claude’s enabledPlugins or Cursor’s team marketplace: subscribe to the catalog, turn plugins on, done. The agent developer should not have to teach the model a custom install ritual, or copy markdown into agent/skills/.
Alternatives considered
- eve extensions — the right primitive for reusable runtime (tools, hooks, connections). A plugin marketplace is for procedural knowledge that already lives in git and is consumed by IDEs. Different job; they compose.
npx skills add / copying into agent/skills/ — a snapshot per agent. It does not stay the company source of truth, and it does not group skills into enableable plugins.- One mega-agent with every skill checked in — collisions and context cost; this is why Cursor treats plugins as optional per project.
What problem are you trying to solve?
Cursor, Claude Code, and other coding agents already have plugins: a company keeps one git repo of domain bundles (iOS conventions, backend review, shared API standards), and each project enables the plugins that apply. Engineers do not copy skills into every repository. A new hire on iOS turns on
shared+ios; a backend repo turns onshared+backend. Updates land in the marketplace once and flow to every consumer.That is the useful unit of sharing inside a company — not a single
SKILL.md, and not “install every skill we have.” A plugin is a named pack. A marketplace is the catalog of those packs, almost always a git repository with a small manifest.eve does not have this layer. Skills are authored under
agent/skills/or installed by copying files into the agent. Extensions are excellent for shipping code (tools, connections, instruction fragments) as a versioned package. They are not a company skill library: they do not let an on-call agent enableinfraand a coding agent enableiosfrom the same catalog, and they do not let that catalog move independently of an npm publish.The result: organizations that already maintain a Cursor/Claude marketplace must re-implement the same idea for eve, or fork skills into each agent. eve would benefit from the same product: point an agent at a marketplace, enable plugins, and those skills become available like local ones.
Proposed solution
Give eve agents a plugin marketplace, in the same spirit as Cursor and Claude Code:
.cursor-plugin/marketplace.json/.claude-plugin/marketplace.json). eve can use its own manifest (.eve-plugin/marketplace.jsonor similar) if that is cleaner. The catalog idea should stay the same so a company is not forced to maintain a third content repo.ios,backend,shared) whose skills live underskills/<name>/SKILL.md, following the Agent Skills layout those other tools already use.load_skillwhen relevant.The authoring experience should feel like Claude’s
enabledPluginsor Cursor’s team marketplace: subscribe to the catalog, turn plugins on, done. The agent developer should not have to teach the model a custom install ritual, or copy markdown intoagent/skills/.Alternatives considered
npx skills add/ copying intoagent/skills/— a snapshot per agent. It does not stay the company source of truth, and it does not group skills into enableable plugins.