Skill-indexer — and an open question about how AI agent skills should be distributed

Discussions
4

Hey, thanks for sharing. That’s an interesting angle on the problem.

On Cursor’s side, the official distribution mechanism is plugins: a directory with a .cursor-plugin/plugin.json manifest. Inside it you can include skills plus rules, hooks, MCP servers, and commands. So for Cursor, “how do I deliver SKILL.md to the consumer” becomes “package it as a plugin”. This doesn’t solve the cross-tooling issue you described, but it does solve it for the Cursor-only case and also gives you versioning and a manifest without relying on npm.

Quick answers to your questions:

  1. npm vs a dedicated registry, IMO this isn’t either-or. npm gives you supply chain stuff like lockfiles, provenance, and audit. A dedicated registry gives curation and discovery. Most ecosystems end up with “packages in npm plus a separate index for discovery” like the VS Code marketplace on top of npm-style packaging. Giving up lockfiles just to get curation is expensive.
  2. Convention plus declarative can both be fine as long as declarative clearly overrides convention. That’s the “convention over configuration, but configuration wins” pattern. It’s only indecisive if they can conflict without a clear priority.
  3. Strict validation on install and lenient rules in dev is a standard split. An --experimental flag or a separate experimentalSkills field in the manifest gives authors runway without polluting the default path for consumers.

Also, for Cursor specifically, it’s worth checking this thread about a parity gap between the IDE and the cursor-agent CLI for skills coming from plugins: Cursor-agent CLI does not register skills from plugins (IDE does — parity gap). If you plan to target both, they currently behave differently.