RFD: Agent Plugins interoperability - #277
Conversation
jackh726
left a comment
jackh726
left a comment
There was a problem hiding this comment.
couple small things, but LGTM overall
| @@ -0,0 +1,234 @@ | |||
| <!-- See .agents/skills/authoring-rfds/SKILL.md for style guidance --> | |||
There was a problem hiding this comment.
leftover of the template, removed
|
|
||
| Symposium installs skills with one mechanism per agent. A skill directory goes to `.claude/skills/` for one agent, `.agents/skills/` for five, and `.kiro/skills/` for another, each with a separate global path. Symposium carries that knowledge itself, and supporting a new agent means learning another placement rule. | ||
|
|
||
| The agents have since converged on a common answer. Every one of them that grew a plugin system settled on the same unit: a directory containing a manifest and a `skills/` folder. Three of the agents Symposium supports read the [Agent Plugins](https://agent-plugins.org/) format directly. Claude Code and Gemini CLI read formats of their own that differ mainly in the manifest filename. Producing that directory lets each agent's own loader perform the placement Symposium performs by hand. |
There was a problem hiding this comment.
The agents have since converged on a common answer.
You say this below, but this is not "technically" true: Claude, Gemini, Goose, and OpenCode haven't officially adopted Agent Plugins from what I can tell.
I think it'd be better to be clear that this is one (preferred) way that we expect to register components, but potentially not the only.
There was a problem hiding this comment.
Fair, overstated.
Rewritten so the convergence is on the unit, like:
- Codex CLI and the Copilot CLI read Agent Plugins,
- Claude Code and Gemini/Antigravity CLI read their own format (close to Agent Plugins, portable)
- OpenCode and Goose have no plugin unit. Preferred where an agent reads it, not the only mechanism, and that now sits in the TL;DR.
| - GitHub Copilot and VS Code read the Agent Plugins format. The Copilot CLI stores packages under `~/.copilot/installed-plugins/`, and VS Code registers local plugin paths through a plugin-locations setting. | ||
| - Codex CLI reads the format as of v0.147.0, from `.codex/plugins/` for a project and `~/.codex/plugins/` for a user. | ||
| - Kiro reads the format as of v1.0.288, where a package is called a power and can be installed from a local folder. | ||
| - Claude Code reads its own near-identical format, a `.claude-plugin/plugin.json` beside `skills/`, `agents/`, and `hooks/`, installed through a local directory marketplace. A package installed this way is recorded as installed but not enabled, so the enablement entry is written as well. | ||
| - Gemini CLI reads extensions, a `gemini-extension.json` beside `skills/`, `commands/`, `hooks/`, and `agents/`, from `~/.gemini/extensions/<name>/`. |
There was a problem hiding this comment.
I'm not entirely sure that this level of detail is needed in this RFD
There was a problem hiding this comment.
Agreed, and it was partly wrong too.
By implementing at #280, showed Codex CLI has no folder discovery, VS Code's chat.pluginLocations is machine-scoped, one directory can carry all three manifests so Claude Code and Gemini CLI need no separate emitters.
Paths and versions are moved to proposed-install.md, which already had the table. The README keeps just the invariant.
Resolves the md/SUMMARY.md conflict with the telemetry-recording RFD, which claimed the same insertion point under Accepted. Keeps both entries, telemetry-recording first since it landed on main.
|
Can you rebase instead, instead of including merge commits? |
3 participants
What does this PR do?
Proposes compiling Symposium plugins into the shared Agent Plugins directory format (manifest +
skills/) that five of the seven supported agents already read, instead of writing skill files into a different per-agent path for each one.plugin.jsonpackage (crate, registry entry, or workspace member) as an ordinary Symposium plugincargo agents sync/use/removepath (no new command)Includes a follow-up commit addressing feedback left on the fork commit: states when directory removal actually happens (next sync where a plugin stops applying, not only on uninstall), forward-references the per-agent dialect breakdown instead of leaving it dangling, and defines what counts as a "broken" skill.
Disclosure questions
AI disclosure.
Questions for reviewers.
Does the version-one boundary (skills only, MCP servers deferred to the meta-server RFD) match the sequencing you'd expect? And does the "Claude Code / Gemini CLI get a separate emitter, same compiled model" framing hold up given how those two formats actually diverge from the standard?