Adopt the Agent Plugins standard (agent-plugins.org)

**What problem would this solve?**

[Agent Plugins](https://agent-plugins.org) is an open, vendor-neutral standard (v1.0.0) for packaging reusable agent components into portable plugins. It defines a shared on-disk format for [Agent Skills](https://agentskills.io/specification) and [MCP servers](https://modelcontextprotocol.io/specification) that any compatible client can discover and load consistently.

An Agent Plugin is a directory with a required manifest plus optional components in fixed locations:

```text
my-plugin/
├── plugin.json # identity + Agent Plugins version targeted
├── skills/
│ └── summarize/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json # stdio, Streamable HTTP, or legacy HTTP+SSE servers
└── com.example.client/ # reverse-domain namespace for client-specific behavior
└── hooks/
```

The spec is deliberately a narrow interoperability floor: distribution, installation, permissions, UX, and client-specific capabilities stay under each client's control. It is developed in public, and the initial Technical Steering Committee includes maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel.

Today goose has its own conventions for skills and extensions. Authors who want their skills or MCP servers to work in goose and elsewhere have to rearrange or duplicate the same underlying components per client. Users can't take a plugin they already have from another client and use it in goose.

**What would a good outcome look like?**

goose can load an Agent Plugins directory and pick up the skills and MCP servers it contains, without the author having to restructure anything for goose specifically. goose appears on the spec's [Compatible Clients](https://agent-plugins.org/compatible-clients) list and satisfies the [client conformance checklist](https://agent-plugins.org/client-implementers/conformance) for the components it chooses to support.

**Possible approaches**

This issue is to track adoption and open the design discussion, not to propose an implementation. Things worth deciding in that discussion:

- Which components goose supports initially (skills only, MCP servers only, or both).
- How plugin-provided skills and MCP servers map onto goose's existing skills and extension configuration.
- Where plugins are discovered from (global vs project-level), and how that interacts with existing enable/disable controls.
- Whether goose wants a `xyz.goose` (or similar) reverse-domain extension namespace for goose-specific behavior such as recipes.
- Trust and permissions: a plugin can bring executable scripts and MCP server commands, so installation and consent need thought.
- The spec is v1.0.0 and evolving; adoption should be scoped so it does not couple goose tightly to details that may still move.

**Additional context**

- Spec docs: https://agent-plugins.org
- Spec repo: https://github.com/agentplugins/agent-plugins-spec
- Client implementer guide: https://agent-plugins.org/client-implementers

- [x] I have verified this does not duplicate an existing feature request

The issue is about integrating the Agent Plugins standard into goose. Start by reading the spec at agent-plugins.org and the client implementer guide. Examine goose's existing code for skills and extensions to understand the current conventions. The discussion points in the issue body outline the key design decisions needed before implementation can begin.

Rédigé par le modèle d'indexation à partir du texte de l'issue.