[FEATURE]: support the Agent Plugins standard (agent-plugins.org)

Describe the enhancement you want to request

OpenCode has no support for Agent Plugins, the vendor-neutral packaging spec for bundling Agent Skills and MCP servers into a portable plugin.

Context

This is a broad, multi-vendor effort rather than any one company's format. Agent Plugins 1.0.0 was published by a TSC of Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel, and Google has since joined as a Core Maintainer.

Support already spans most major agent clients:

The first four rows are per the launch announcement; Google's two are per its Core Maintainer announcement above, with more of its products to follow.

OpenCode is a conspicuous omission, and it's the one place a user's skills currently don't follow them.

Both a client implementation and conformant plugins already exist to test against:

• Codex implements it as of 0.147.0 (2026-08-07), via openai/codex#36544. Root plugin.json now takes precedence, with the legacy .codex-plugin/plugin.json demoted to an optional overlay.
• AWS's agent-toolkit-for-aws shipped conformant manifests for all four of its plugins in #214 (2026-08-06).

Those AWS plugins install in Codex today. In OpenCode the same directories are only reachable if a user points skills.paths at them by hand, and their bundled MCP servers are not picked up at all.

What the format is

plugin-name/
├── plugin.json          # $schema: https://agent-plugins.org/schemas/1.0.0/plugin.schema.json
├── skills/              # Agent Skills (agentskills.io), which OpenCode already understands
├── mcp.json             # $schema: .../1.0.0/mcp.schema.json
└── com.example.client/  # reverse-domain namespace for client-specific extensions

Notably, OpenCode already discovers ~/.claude/skills/** and ~/.agents/skills/** and already speaks MCP. The gap is only the manifest layer that binds them into one installable, versioned unit.

Proposal

1. Recognize a root plugin.json as a plugin manifest, gated on $schema matching https://agent-plugins.org/schemas/1.0.0/plugin.schema.json. Codex treats a non-matching or absent $schema as "not an Agent Plugin" and falls through, which seems like the right behaviour, since it keeps unrelated plugin.json files from being misread.
2. Load skills/ through the existing skill discovery path.
3. Load mcp.json into the existing MCP server config, honouring the spec's transport rules (§7.2.1).
4. Optionally consume .agents/plugins/marketplace.json for discovery. Both Codex's own curated marketplace and AWS's toolkit already publish at that vendor-neutral path.
5. Optionally reserve a com.opencode.* (or similar) extension namespace per §8.2 for anything OpenCode-specific.

Relationship to existing issues

• #40629 asks for discovery of skills sitting inside VS Code agent-plugin and Claude Code plugin directories, by reading each client's own manifests (installed.json, cache.json, installed_plugins.json). That's a per-client compatibility shim; Agent Plugins is the standard that makes such shims unnecessary for conformant packages. The two are complementary, one covering what's already installed today and the other what gets published going forward.
• #40085 (closed) proposed a unified OpenCode marketplace. Supporting the spec would let such a marketplace serve portable packages rather than an OpenCode-only format.