Roadmap beyond skills + MCP?

[not-stbenjam]

This is great to see. A vendor-neutral packaging format is badly needed, and I undertand skills + MCP are largely agreed on by everyone. I maintain skillsaw, an open-source linter for agentic context files. Implementing several vendors' formats side by side left me with some questions about where this is heading.

The most obvious missing piece is marketplaces, why was no marketplace format decided? For example, it appears Agent Plugins aren't actually installable standalone in Codex CLI as far as I can tell -- without using their proprietary marketplace format.

What's on the roadmap past v1.0.0?

Markpetplaces

.agents/ reads like the shared namespace. .agents/skills/ is honored across tools. But Codex puts its marketplace catalog at .agents/plugins/marketplace.json. As they are part of this, was it a proposal to adopt this but rejected? A vendor-specific format currently sits in what otherwise looks like commons.

Other primitives/features

Are there any plans to support....

• Dependency management between plugins
• Signing (e.g. SigStore)
• Packaged agent definitions
• Path-scoped rules and instructions, meaning conditional guidance like "when editing **/*.tf, do X". Probably the least standardized of the lot, with the highest value. Monolithic AGENTS.md are out of style IMHO.
• LSP integration
• Marketplaces
• Hooks. I see the Hookbridge thread already exploring interop
• Commands (but it is probably right to just favor user-invocable skills)

[HadjievK]

Next step probably is an open standard for Agent Marketplaces. Like Claude marketplace which is the top package unit - including plugins etc…

[bobleer]

I would vote for hooks before marketplaces, mostly because a marketplace can already distribute the existing package while hooks are where portability still falls apart.

In BitFun we ended up supporting Skills/MCP alongside the Codex hook contract. The sharp edge is the lifecycle and policy around a capability: that part does not travel with the plugin today.

A small useful step might be a manifest-declared hooks component pointing at a versioned contract. The host would still own execution, sandboxing, and permission prompts, so the package cannot smuggle policy in. That feels narrow enough to standardize without flattening every vendor agent/command model at once.

Happy to write up the implementation edges we hit if proposals are welcome: https://github.com/GCWing/BitFun

[rnett]

I would also add subagents to the list, IMO it's the biggest missing item. Most agents use a very similar skill-like format already.

[willvelida]

The most obvious missing piece is marketplaces, why was no marketplace format decided? For example, it appears Agent Plugins aren't actually installable standalone in Codex CLI as far as I can tell -- without using their proprietary marketplace format.

There's some fun challenges to solve around provenance verification that need to be solved as part of defining a marketplace format, which have been listed in the future considerations doc.

Probably worth it's own discussion thread.

[wommy]

hooks > subagents but a close second
slim to nil use for a marketplace

[hsperker]

+1 to packaged agent definitions, with a caveat.

"Subagent" bundles two things: a role declaration and a delegation mechanism. Only the declaration is portable.

I tested a candidate shape against eight framework runtimes and four declarative formats, field by field. name plus Markdown instructions survived everywhere except CrewAI, which fuses identity, description and instructions into one template. description, skills references and plugins references survived when present. A generic delegates field did not, because it hid six different mechanisms behind one word. Per-field matrix: https://github.com/hsperker/agent-composition-profile/blob/main/generated/runtime/matrix.md

So the portable unit is smaller than a subagent. It is the declaration. Whether a host runs it as a delegate, an isolated session, or the main agent stays with the host.

Appendix D.2 defined almost exactly this before f0d7a31 removed it: name, description, and the Markdown body as the system prompt.

@stbenjam, a direct question: would skillsaw check a shape like that? A linter validating one profile against several vendors' native formats produces the cross-host evidence this needs, and you already have the parsers.

Adapters and locked environments are in the same repo if anyone wants to reproduce it: https://github.com/hsperker/agent-composition-profile

No argument with hooks going first.

@bioinfornatics has a fuller proposal for this in #70, including workflows.

[stbenjam]

@stbenjam, a direct question: would skillsaw check a shape like that? A linter validating one profile against several vendors' native formats produces the cross-host evidence this needs, and you already have the parsers.

If a basic portable shape were standardized, with vendor-specific extensions layered on top, skillsaw could absolutely lint the common spec and then validate each vendor's custom fields separately when detected. That's essentially how agentskills.io work today.

The world is a chaotic mess but I've tried my best to make reasonable choices. Agents in particular have some odd conflicts. I believe OpenCode expects hex colors for the color field, which doesn't work at all in some harnesses - which return an error make the agent unusable. The challenge is always compatibility.

We'd need agreement on a basic format which I assume is why Agent Plugins hasn't tackled most primitives.

[hsperker]

That layering is what I ended up with: small required core, optional fields a strict host preserves or rejects, vendor fields untouched. The color conflict argues for keeping that core small and for an explicit passthrough rule.

One question. What's skillsaw's bar for adding a lint target? Ratification by Agent Plugins, some number of independent implementations, or something else?

Current shape: https://github.com/hsperker/agent-composition-profile/tree/main/spec

[stbenjam]

Wide adoption, but skillsaw supports plugins. https://github.com/stbenjam/skillsaw/blob/main/.agents/skills/skillsaw-issue-triage/references/feature-evaluation.md largely covers the criteria