Compatible plugin marketplaces
Any git repository carrying one of the supported manifests can be added as a source. One repo may carry several dialects at once; identity follows manifest precedence while declared component paths resolve into resources shared by discovery, runtime and detail views.
Repositories and format references
Reference project for the Claude Code ecosystem; this list includes format references as well as suite repositories.
Multi-client repo that ships agent-plugins, .claude-plugin, .cursor-plugin and .kimi-plugin manifests at once — a good stress test for dialect precedence.
The portable agent-plugins.org v1.0.0 suite spec. Suites with plugin.json are validated against the vendored 1.0.0 JSON Schema.
This list is community-maintained — open a PR to add a marketplace you tested.
Layout support does not imply full compatibility with the original platform. Project commands, supported JSON/Codex TOML MCP configurations and mapped command hooks mount in the calling agent's scope. The scanProjectLayouts setting controls native project discovery. Project LSP is diagnosed and not mounted; host API changes are outside this plugin's scope.
What gets injected
- Supported skills enter the host skill catalog; root placeholders are substituted and invocation settings are respected.
- Valid MCP declarations use the built-in bridge by default; optional host-client compatibility mode is available.
hooks/hooks.jsonbridges to DSH interception points: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, SubagentStart, SubagentStop.- Commands use the host slash registry. Roles enter a dynamic subagent catalog and run through subagent_run with their saved provider, model, reasoning effort and tool restrictions; this requires host agents, tools, LLM and subagents.
- LSP declarations mount through the LSP packages the plugin installs itself; only the language-server executable has to be on PATH.
Shared layout precedence
Suite manifests and Marketplace catalogs follow the same layout order. Catalog lookup skips layouts without a dedicated catalog; aliases follow the order shown.
| Layout (highest priority first) | Suite manifest | Marketplace catalog |
|---|---|---|
| agent-plugins / root compatibility | plugin.json | No dedicated catalog |
| Universal | .plugin/plugin.json | .plugin/marketplace.json |
| Claude Code | .claude-plugin/plugin.json | .claude-plugin/marketplace.json |
| Cursor | .cursor-plugin/plugin.json | .cursor-plugin/marketplace.json |
| Kimi Code | kimi.plugin.json, then .kimi-plugin/plugin.json | .kimi-plugin/marketplace.json |
| Codex | .codex-plugin/plugin.json | .agents/plugins/marketplace.json, then .agents/plugins/api_marketplace.json |
| ZCode | .zcode-plugin/plugin.json | No dedicated catalog |
| Qoder CLI | .qoder-plugin/plugin.json | .qoder-plugin/marketplace.json |
| GitHub Copilot CLI | .github/plugin/plugin.json | .github/plugin/marketplace.json |
| Fallback: skill collection / shared catalog | Discover skills when no recognized manifest exists | Root marketplace.json |
Manifest selection uses the first existing file and fails closed if it is invalid. Root plugin.json uses strict v1 validation only with a recognized agent-plugins.org schema; otherwise it is Claude-compatible. Catalog scanning selects the first catalog that produces suites; invalid or empty catalogs allow later candidates. Root marketplace.json is a shared fallback, not a v1 or skill-collection catalog, and does not inherit root manifest priority.
All ten active schema layouts have offline README-repository tests, including isolated variants that suppress competing manifests at nested suite roots. Cursor, Kimi, Qoder, Copilot, Universal and root marketplace files are recognized alongside Claude Code and Codex catalogs. The compatibility report exercises every schema against one real repository and records the commit, the schema verdict and what the scanner did with it.