# Referencia del plugin CLI de GitHub Copilot
Busque comandos y detalles de configuración para los complementos de la CLI.
> \[!NOTE]
> Puede encontrar ayuda sobre el uso de complementos escribiendo `copilot plugin [SUBCOMMAND] --help` en el terminal.
Para obtener información general sobre qué son los complementos y cómo funcionan en los Copilot clientes, consulte [Información sobre GitHub Copilot complementos](/es/copilot/concepts/agents/about-plugins).
## Comandos de la CLI
Puede usar los siguientes comandos en el terminal para administrar complementos para Copilot CLI.
`copilot plugins` (plural) es un alias heredado para `copilot plugin`: ambos se resuelven en el mismo comando.
| Comando | Descripción |
| ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `copilot plugin install SPECIFICATION` (también conocido como `add`) | Instale un complemento. Consulte la [especificación del complemento para el comando `install` que se encuentra a continuación](#plugin-specification-for-install-command). |
| `copilot plugin uninstall NAME` (alias `remove`, `rm`) | Quitar un complemento |
| `copilot plugin list` | Enumerar complementos instalados |
| `copilot plugin update NAME` | Actualice un complemento con nombre. Use `--all` para actualizar todos los complementos instalados a la vez. |
| `copilot plugin enable NAME` | Habilite un complemento deshabilitado anteriormente. El cambio persiste en la configuración y se aplica a futuras sesiones. Esto funciona para las instalaciones de Marketplace e instalaciones directas (desde `owner/repo`, una dirección URL o una ruta de acceso local) por igual. |
| `copilot plugin disable NAME` | Deshabilite un complemento sin desinstalarlo. Un `--plugin-dir` montaje permanece de solo lectura, ya que no tiene ninguna activación persistente para cambiar. |
| `copilot plugin marketplace add SPECIFICATION` | Registrar un marketplace. El propio nombre del mercado, tomado de su `marketplace.json` manifiesto, se convierte en su clave de registro; no hay ninguna opción para definir un nombre local personalizado. |
| `copilot plugin marketplace list` | Enumeración de marketplaces registrados |
| `copilot plugin marketplace browse NAME` | Análisis de complementos de Marketplace |
| `copilot plugin marketplace update [NAME]` (también conocido como `refresh`) | Volver a recuperar el catálogo de complementos de un mercado. Omita `NAME` para actualizar los catálogos de todos los mercados registrados. |
| `copilot plugin marketplace remove NAME` | Anule el registro de un marketplace. Se rechaza si aún hay complementos del mercado instalados; pasa `--force` para desinstalar también esos complementos. |
Antes de que `copilot plugin` se dividiera en comandos independientes por recurso, `copilot plugins` también inspeccionaba y activaba o desactivaba servidores MCP, habilidades, instrucciones y servidores de idiomas mediante las opciones `--kind`, `--scope`, `--mcp` y `--skill`. Se han eliminado esos indicadores entre tipos. En su lugar, use los comandos dedicados [`copilot mcp`](/es/copilot/reference/copilot-cli-reference/cli-command-reference#copilot-mcp-subcommand), [`copilot skill`](/es/copilot/reference/copilot-cli-reference/cli-command-reference#managing-skills-non-interactively), [`copilot instruction`](/es/copilot/reference/copilot-cli-reference/cli-command-reference#using-copilot-instruction)y [`copilot lsp`](/es/copilot/reference/copilot-cli-reference/cli-command-reference#using-copilot-lsp) .
`copilot plugin list --json` ahora emite una matriz plana de complementos en lugar del objeto anterior `{ plugins, errors }` .
> \[!NOTE]
> Un complemento o tienda fijado por una organización o por una directiva gestionada por MDM (`enabledPlugins`, `extraKnownMarketplaces`) no se puede volver a habilitar, deshabilitar ni redirigir localmente: el valor gestionado prevalece para esa entrada. El panel de control `/plugin` marca estas filas con una insignia `Managed` y rechaza cualquier cambio que entre en conflicto. Consulte [directorio de configuración de la CLI de GitHub Copilot](/es/copilot/reference/copilot-cli-reference/cli-config-dir-reference#mdm-managed-settings).
>
> Un complemento cuya activación está determinada actualmente por la superposición `enabledPlugins` del repositorio actual rechaza `copilot plugin enable`/`disable` en lugar de guardar de forma silenciosa un valor global que no tendría ningún efecto en ese repositorio. El error asigna un nombre al archivo de configuración que controla realmente el complemento. Consulte [directorio de configuración de la CLI de GitHub Copilot](/es/copilot/reference/copilot-cli-reference/cli-config-dir-reference#repository-settings-githubcopilotsettingsjson).
### Especificación para el comando del complemento `install`
| Formato | Ejemplo | Descripción |
| --------------------------- | ---------------------------- | ----------------------------------- |
| Marketplace | `plugin@marketplace` | Plugin de un marketplace registrado |
| GitHub | `OWNER/REPO` | Raíz de un GitHub repositorio |
| GitHub subdir | `OWNER/REPO:PATH/TO/PLUGIN` | Subdirectorio en un repositorio |
| Git URL | `https://github.com/o/r.git` | Cualquier dirección URL de Git |
| Ruta de acceso local | | |
| `./my-plugin` o `/abs/path` | Directorio local | |
### `copilot plugin list` Opciones
| Option | Descripción | |
| ------------------------ | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| `--json` | Emita una matriz JSON plana de complementos en lugar de texto. | |
| `--config-dir=DIRECTORY` | Ruta de acceso al directorio de configuración. Esta opción está en desuso. Utilice `COPILOT_HOME` en su lugar. | |
Cada `--json` fila tiene la forma `{ name, marketplace?, version?, enabled, source, installedFrom? }`.
### `copilot plugin enable`/`disable` opciones
| Option | Descripción | |
| ------------------------ | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| `--config-dir=DIRECTORY` | Ruta de acceso al directorio de configuración. Esta opción está en desuso. Utilice `COPILOT_HOME` en su lugar. | |
### `copilot plugin install` Opciones
Para instalar una skill en lugar de un complemento, utiliza [`copilot skill add`](/es/copilot/reference/copilot-cli-reference/cli-command-reference#managing-skills-non-interactively); no se trata de la instalación de un complemento ni se realiza a través de un marketplace.
| Option | Descripción | |
| ------------------------ | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| `--config-dir=DIRECTORY` | Ruta de acceso al directorio de configuración. Esta opción está en desuso. Utilice `COPILOT_HOME` en su lugar. | |
Los servidores MCP se instalan desde un registro configurado por directivas, lo que requiere autenticación e entrada secreta interactiva. Use la vista **En línea** del `/mcp` panel o el [`copilot mcp add`](/es/copilot/reference/copilot-cli-reference/cli-command-reference#copilot-mcp-subcommand) comando para agregar servidores MCP en lugar de `copilot plugin install`.
### `copilot plugin update` Opciones
| Option | Descripción | |
| ------------------------ | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| `--all` | Actualizar todos los complementos instalados | |
| `--config-dir=DIRECTORY` | Ruta de acceso al directorio de configuración. Esta opción está en desuso. Utilice `COPILOT_HOME` en su lugar. | |
> \[!NOTE]
> Los complementos con ruta de origen en un mercado local (de origen en directorio) se cargan en tiempo real desde su directorio real; al editar uno, el cambio surte efecto en `/restart` o en una nueva sesión, sin necesidad de `copilot plugin update`.
Los plugins propios (los instalados desde marketplace integrado `awesome-copilot` ) se actualizan automáticamente al principio de cada sesión en un directorio de trabajo de confianza. Deshabilite este comportamiento con la opción `autoUpdate` (establecida en `false`) o la variable de entorno `COPILOT_AUTO_UPDATE=false`. La actualización automática también se omite de forma predeterminada en CI. Consulte [directorio de configuración de la CLI de GitHub Copilot](/es/copilot/reference/copilot-cli-reference/cli-config-dir-reference#configuration-file-settings).
> \[!NOTE]
> `copilot-plugins` anteriormente distribuido como un segundo marketplace predeterminado integrado junto con `awesome-copilot`. Ahora es un marketplace normal y no predeterminado (`github/copilot-plugins`) en el que te registras con `copilot plugin marketplace add github/copilot-plugins`. Si instaló complementos desde él antes de este cambio, una migración única lo agrega a su propio `extraKnownMarketplaces` con `autoUpdate: true` para que esos complementos sigan actualizándose. Una instalación nueva que nunca ha usado `copilot-plugins` debe registrar `copilot-plugins` manualmente antes de instalar complementos desde este.
Un mercado que hayas añadido tú mismo puede activarse para la misma actualización automática al inicio de la sesión configurando `autoUpdate: true` en su entrada `extraKnownMarketplaces` en tu configuración de usuario. Esta opción de activación solo se aplica a las sesiones interactivas y `-p`; las sesiones de SDK y de servidor no se actualizan automáticamente. Se respeta la configuración del usuario o la configuración administrada (MDM/servidor), pero se acepta e ignora una configuración `autoUpdate` en el nivel de repositorio; esta no puede habilitar ni redirigir la actualización automática de un marketplace. En caso de conflicto de nombres, tiene prioridad el marketplace propio integrado, seguido de una entrada administrada (que sustituye por completo a la entrada de usuario con el mismo nombre, por lo que una entrada administrada sin `"autoUpdate": true` elimina la opción de participación del usuario) y, por último, la propia entrada del usuario. Consulte [Configuración del repositorio](/es/copilot/reference/copilot-cli-reference/cli-config-dir-reference#repository-settings-githubcopilotsettingsjson).
En modo interactivo, `/plugin` señala un complemento o un mercado instalado cuando hay una versión más reciente disponible en el origen, y ofrece una acción **Actualizar** desde el panel de control para descargarla.
### `copilot plugin marketplace` (alias `marketplaces`) subcomandos
El marketplace predeterminado integrado `awesome-copilot` se incluye con el tiempo de ejecución y no se puede quitar.
| Subcommand | Descripción |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| `list [--json]` | Enumera todos los marketplaces registrados, incluido el valor predeterminado integrado |
| `add SOURCE` | Agregar un marketplace (`owner/repo`, , `owner/repo#ref`una dirección URL o una ruta de acceso local) |
| `remove NAME [--force]` | Quitar un marketplace; `--force` también desinstala los complementos procedentes de él. |
| `browse NAME [--json]` | Enumeración de los complementos ofrecidos por el catálogo de Marketplace |
| `update [NAME]` (también conocido como `refresh`) | Actualizar el catálogo de plugins de un marketplace o el de todos si se omite `NAME` |
En modo interactivo, ejecute `/plugin marketplace update [NAME]` (alias `/plugin marketplace refresh`) o presione R en la vista **marketplace** del `/plugin` panel para actualizar cada catálogo de Marketplace registrado.
## `plugin.json`
Todos los complementos constan de un directorio de complementos que contiene un archivo de manifiesto denominado `plugin.json`. Agent Plugins requiere el manifiesto en la raíz del plugin. Una raíz `plugin.json` que tiene como destino los complementos del agente tiene prioridad sobre `.plugin/plugin.json` y `.claude-plugin/plugin.json` por especificación §5.1. Los complementos heredados admiten las ubicaciones alternativas enumeradas en [Ubicaciones de archivos](#file-locations). Consulte [Creación de un complemento para GitHub Copilot CLI](/es/copilot/how-tos/copilot-cli/customize-copilot/plugins-creating).
Copilot CLI admite tanto el manifiesto heredado del complemento como el manifiesto de Agent Plugins.
Copilot CLI reconoce los valores canónicos `$schema` para Agent Plugins (Especificación abierta de plugins) v1.0.0 (`https://agent-plugins.org/schemas/1.0.0/plugin.schema.json`) y v1.1.0 (`https://agent-plugins.org/schemas/1.1.0/plugin.schema.json`), haciendo que un plugin adopte la semántica de Agent Plugins. Un manifiesto sin uno de estos valores exactos usa el formato heredado y se carga como antes. Si un complemento declara una versión de Agent Plugins que Copilot CLI no admite, la CLI rechaza el complemento en lugar de volver silenciosamente al modo heredado. Un complemento rechazado no aporta hooks, servidores LSP, servidores MCP, habilidades, comandos, agentes, reglas ni directorios de extensiones.
### Campos del manifiesto de Agent Plugins 1.0
Los complementos del agente 1.0 definen un esquema de manifiesto cerrado. Para conocer los requisitos de formato completos, consulte la [especificación Agent Plugins 1.0](https://github.com/agentplugins/agent-plugins-spec/blob/main/spec/1.0.0.md).
Se permiten los siguientes campos:
| Campo | Tipo | Obligatorio | Descripción |
| ------------- | --------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `$schema` | cuerda / cadena | Sí | Debe ser una URL reconocida de Agent Plugins `$schema` (v1.0.0 o v1.1.0). Se rechazan las versiones de complementos de agente no compatibles. |
| `name` | cuerda / cadena | Sí | Nombre del complemento. Consulte [Restricciones de nombre](#name-constraints). |
| `version` | cuerda / cadena | No | Cadena de versión. Se recomienda el versionado semántico. |
| `description` | cuerda / cadena | No | Breve descripción. |
| `author` | objeto | No | Campos de cadena opcionales `email`, `url` y `name`. |
| `homepage` | cuerda / cadena | No | Página principal o documentación del complemento. |
| `repository` | cuerda / cadena | No | Repositorio de origen. |
| `license` | cuerda / cadena | No | Identificador de licencia. Se recomienda un identificador SPDX. |
| `keywords` | string\[] | No | Palabras clave de búsqueda y detección. |
| `extensions` | objeto | No | Datos específicos del cliente indexados por el espacio de nombres de dominio inverso. |
Los campos de nivel superior desconocidos se notifican y se ignoran. Los campos de ruta del componente, como `agents`, `skills`, `hooks`, `mcpServers` y `lspServers`, no son campos del manifiesto de Agent Plugins 1.0.
#### Restricciones de nombre
El nombre de un complemento de Agent Plugins 1.0 debe:
* Contienen entre 1 y 64 caracteres.
* Solo contienen letras ASCII minúsculas, dígitos, guiones y puntos.
* Comience y termine con un carácter alfanumérico.
* No contiene `--` ni `..`.
#### Componentes
Agent Plugins 1.0 define dos tipos de componentes portátiles:
* Habilidades en los subdirectorios inmediatos de `skills/` que contienen un archivo `SKILL.md`.
* Servidores MCP en la raíz del complemento `mcp.json`.
Estas ubicaciones son fijas y no se pueden configurar en `plugin.json`. Las aptitudes se cargan solo desde `skills/`: no hay alternativa en `SKILL.md` raíz (los complementos heredados recurren a un `SKILL.md` raíz cuando no existe ningún directorio `skills/`). El elemento raíz `mcp.json` debe declarar una versión reconocida de los complementos del agente `$schema` (que coincida con la versión de `plugin.json`) en el campo `$schema`. El contenedor de nivel superior está cerrado, y cada entrada de servidor se valida con respecto a su esquema de transporte; las entradas de servidor no válidas se omiten de forma individual, mientras que las válidas sí se cargan. La CLI acepta los nombres de transporte MCP `stdio`, `streamable-http` y `sse`.
Para los servidores `stdio`, la CLI proporciona `PLUGIN_ROOT` y `PLUGIN_DATA` en el entorno del subproceso. Amplía `COPILOT_PLUGIN_DATA` y `CLAUDE_PLUGIN_DATA` (además de los alias `env` y `cwd`) en los valores `args` y `${PLUGIN_DATA}` del servidor, y en `${PLUGIN_ROOT}`.
`PLUGIN_DATA` apunta a un directorio persistente y grabable para el complemento instalado. Los valores de configuración remotos del servidor `http`, `sse` y `streamable-http` se transfieren literalmente, sin expansión de marcadores de posición ni de variables de entorno.
Los complementos de agente 1.0 no definen agentes portátiles, enlaces, comandos, reglas o servidores LSP. Estos siguen siendo específicos del cliente. Los datos del manifiesto específicos del cliente deben ir en `extensions`, indexados mediante un espacio de nombres de dominio inverso. Los archivos específicos del cliente pertenecen a un directorio de nivel superior con el mismo espacio de nombres. Los clientes omiten los espacios de nombres que no admiten.
Copilot CLI lee sus componentes específicos del cliente del directorio `com.github.copilot`:
| Componente | Location |
| -------------------------- | ------------------------------------- |
| Agentes personalizados | `com.github.copilot/agents/` |
| Comandos de barra diagonal | `com.github.copilot/commands/` |
| Reglas | `com.github.copilot/rules/` |
| Hooks | `com.github.copilot/hooks/hooks.json` |
| Servidores LSP | `com.github.copilot/lsp.json` |
Estas ubicaciones solo se aplican a los plugins de Agent Plugins 1.0. Los plugins heredados siguen utilizando las ubicaciones de sus componentes y los campos de ruta del manifiesto.
### Ejemplo de archivo `plugin.json` de Agent Plugins 1.0
```json copy
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "my-dev-tools",
"description": "React development utilities",
"version": "1.2.0",
"author": {
"name": "Jane Doe",
"email": "jane@example.com"
},
"license": "MIT",
"keywords": ["react", "frontend"]
}
```
### Campos de manifiesto heredados
#### Campo obligatorio
| Campo | Tipo | Descripción |
| ------ | --------------- | -------------------------------------------------------------------------------------------- |
| `name` | cuerda / cadena | Nombre del complemento kebab-case (solo letras, números y guiones). Máximo de 64 caracteres. |
#### Campos de metadatos opcionales
| Campo | Tipo | Descripción |
| ----------------------------------------------------------- | --------------- | ----------------------------------------------- |
| `description` | cuerda / cadena | Breve descripción. Máximo de 1024 caracteres. |
| `version` | cuerda / cadena | Versión semántica (por ejemplo, `1.0.0`). |
| `author` | objeto | |
| `name` (obligatorio), `email` (opcional), `url` (opcional). | | |
| `homepage` | cuerda / cadena | Url de la página principal del complemento. |
| `repository` | cuerda / cadena | Dirección URL del repositorio de origen. |
| `license` | cuerda / cadena | Identificador de licencia (por ejemplo, `MIT`). |
| `keywords` | string\[] | Buscar palabras clave. |
| `category` | cuerda / cadena | Categoría del complemento. |
| `tags` | string\[] | Etiquetas adicionales. |
#### Campos de ruta de acceso de componente
Estos indican a la CLI dónde encontrar los componentes del complemento. Todos son opcionales. La CLI utiliza convenciones predeterminadas si se omiten ciertos parámetros.
| Campo | Tipo | Predeterminado | Descripción |
| ------------ | ----------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `agents` | cadena \| cadena\[] | `agents/` | Rutas hacia directorios de agentes (archivos `.agent.md`). |
| `skills` | cadena \| cadena\[] | `skills/` | Rutas de acceso a los directorios de habilidades (`SKILL.md` archivos). |
| `commands` | cadena \| cadena\[] | — | Rutas de acceso a directorios de comandos. |
| `hooks` | string \| objeto | — | Ruta a un archivo de configuración de hooks o a un objeto de hooks en línea. |
| `extensions` | string \| string\[] \| object | — | Rutas de acceso a directorios de extensión. Use `{ paths: [...], exclusive: true }` para suprimir las extensiones integradas. En [los manifiestos de Agent Plugins 1.0](#agent-plugins-10-manifest-fields), este campo tiene un significado diferente. |
| `mcpServers` | string \| objeto | — | Ruta de acceso a un archivo de configuración MCP (por ejemplo, `.mcp.json`) o definiciones de servidor insertadas. |
| `lspServers` | string \| objeto | — | Ruta de acceso a un archivo de configuración de LSP, o definiciones de servidor integradas. |
#### Servidores MCP de agentes incluidos en el complemento
Un agente incluido en un complemento puede declarar su propio `mcp-servers` en su frontmatter, limitando un servidor MCP únicamente a ese agente en lugar de exponerlo mediante la configuración compartida `mcpServers` del complemento. Dentro de ese `mcp-servers` bloque, `${PLUGIN_ROOT}` (o sus/`${CLAUDE_PLUGIN_ROOT}``${COPILOT_PLUGIN_ROOT}` alias) se expande al directorio raíz del complemento, por lo que el servidor `command` o `args` puede apuntar a un script agrupado con el complemento:
```markdown
---
name: Plugin Linter
description: Runs the plugin's bundled linter via its own MCP server
mcp-servers:
plugin-linter:
command: node
args: ["${PLUGIN_ROOT}/tools/serve.js"]
tools: ["*"]
---
You are a linting specialist for this plugin's bundled rules.
```
Esta sustitución solo se aplica a `mcp-servers` en el frontmatter propio de un agente suministrado por un complemento; no se extiende ni a `${PLUGIN_DATA}` ni a las variables de entorno del servidor. Los agentes del espacio de trabajo y del usuario no tienen una raíz de complemento, por lo que sus metadatos de cabecera se dejan sin cambios.
### Configuración del servidor LSP
Para incluir servidores LSP (protocolo de servidor de idiomas) en un complemento, cree un archivo `lsp-config/servers.json` en el directorio del complemento, o especifique una ruta de acceso o un objeto en línea mediante el campo `lspServers` de `plugin.json`.
Ejemplo `lsp-config/servers.json` (o en línea mediante `lspServers` en `plugin.json`):
```json
{
"lspServers": {
"my-lsp": {
"command": "my-language-server",
"fileExtensions": { ".myext": "mylang" }
}
}
}
```
Para la compatibilidad multiplataforma, use `bash` y `powershell` en lugar de `command`:
```json
{
"lspServers": {
"my-lsp": {
"bash": "${PLUGIN_ROOT}/scripts/start-lsp.sh",
"powershell": "${PLUGIN_ROOT}/scripts/start-lsp.ps1",
"fileExtensions": { ".myext": "mylang" }
}
}
}
```
| Campo | Tipo | Obligatorio | Descripción |
| ----------------------- | --------------- | ----------- | ---------------------------------------------------------------------------------------------------- |
| `command` | cuerda / cadena | \* | Ejecutable para iniciar el servidor de lenguaje. |
| `bash` | cuerda / cadena | \* | Script de Bash para iniciar el servidor (Linux/macOS); ejecutado a través de `bash -c SCRIPT`. |
| `powershell` | cuerda / cadena | \* | Script de PowerShell para iniciar el servidor (Windows); se ejecuta a través de `pwsh -c SCRIPT`. |
| `cwd` | cuerda / cadena | No | Directorio de trabajo. Absoluto o relativo al archivo de configuración. Admite `${PLUGIN_ROOT}`. |
| `args` | string\[] | No | Argumentos para pasar a `command` (se ignora para `bash` y `powershell`). |
| `env` | objeto | No | Variables de entorno que se establecerán al generar el servidor. |
| `fileExtensions` | objeto | Sí | Mapa de extensiones de archivo a identificadores de idioma (por ejemplo, `{ ".ts": "typescript" }`). |
| `rootUri` | cuerda / cadena | No | Raíz del proyecto relativa a la raíz de Git (valor predeterminado: `.`). |
| `initializationOptions` | cualquiera | No | Opciones enviadas al servidor en la solicitud LSP `initialize` . |
(\*) Se requiere al menos uno de `command`, `bash`o `powershell` . Cuando se especifican `bash` y `powershell`, se selecciona automáticamente la adecuada para la plataforma (PowerShell en Windows, Bash en otro lugar).
Use `${PLUGIN_ROOT}` para hacer referencia a rutas de acceso dentro del directorio del complemento.
## `marketplace.json`
Puede crear un marketplace de complementos ,que los usuarios pueden usar para detectar e instalar los complementos, creando un `marketplace.json` archivo y guardándolo en el `.github/plugin/` directorio del repositorio. También puede almacenar el `marketplace.json` archivo en el sistema de archivos local. Por ejemplo, guardar el archivo como `/PATH/TO/my-marketplace/.github/plugin/marketplace.json` le permite agregarlo a la CLI mediante el siguiente comando:
```shell
copilot plugin marketplace add /PATH/TO/my-marketplace
```
> \[!NOTE]
> Copilot CLI también busca el archivo `marketplace.json` en el directorio `.claude-plugin/`.
Para obtener más información, vea [Creación de un marketplace de complementos para GitHub Copilot CLI](/es/copilot/how-tos/copilot-cli/customize-copilot/plugins-marketplace).
### Archivo `marketplace.json` de ejemplo
```json copy
{
"name": "my-marketplace",
"owner": {
"name": "Your Organization",
"email": "plugins@example.com"
},
"metadata": {
"description": "Curated plugins for our team",
"version": "1.0.0"
},
"plugins": [
{
"name": "frontend-design",
"description": "Create a professional-looking GUI ...",
"version": "2.1.0",
"source": "./plugins/frontend-design"
},
{
"name": "security-checks",
"description": "Check for potential security vulnerabilities ...",
"version": "1.3.0",
"source": "./plugins/security-checks"
}
]
}
```
> \[!NOTE]
> El valor del `source` campo para cada complemento es la ruta de acceso al directorio del complemento, en relación con la raíz del repositorio. No es necesario usar `./` al principio de la ruta de acceso. Por ejemplo, `"./plugins/plugin-name"` y `"plugins/plugin-name"` se resuelven en el mismo directorio.
### Campos `marketplace.json`
#### Campos de nivel superior
| Campo | Tipo | Obligatorio | Descripción |
| ---------------------------------------------------------------- | --------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | cuerda / cadena | Sí | Nombre de Marketplace en formato kebab-case. Máximo de 64 caracteres. También se admiten puntos (por ejemplo, `acme.tools`) en los complementos de [Agent Plugins 1.0](#agent-plugins-10-manifest-fields). |
| `owner` | objeto | Sí | |
| `{ name, email? }` : información del propietario de Marketplace. | | | |
| `plugins` | array | Sí | Lista de entradas del complemento (consulte la tabla siguiente). |
| `metadata` | objeto | No | `{ description?, version?, pluginRoot? }` |
#### Campos de entrada del complemento (objetos dentro de la `plugins` matriz)
| Campo | Tipo | Obligatorio | Descripción |
| ------------- | ------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | cuerda / cadena | Sí | Nombre del complemento kebab-case. Máximo de 64 caracteres. También se aceptan puntos en los plugins de [Agent Plugins 1.0](#agent-plugins-10-manifest-fields). |
| `source` | string \| objeto | Sí | Dónde capturar el complemento (ruta de acceso relativa, GitHubo dirección URL). |
| `description` | cuerda / cadena | No | Descripción del complemento. Máximo de 1024 caracteres. |
| `version` | cuerda / cadena | No | Versión del complemento. |
| `author` | objeto | No | `{ name, email?, url? }` |
| `homepage` | cuerda / cadena | No | Url de la página principal del complemento. |
| `repository` | cuerda / cadena | No | Dirección URL del repositorio de origen. |
| `license` | cuerda / cadena | No | Identificador de licencia. |
| `keywords` | string\[] | No | Buscar palabras clave. |
| `category` | cuerda / cadena | No | Categoría del complemento. |
| `tags` | string\[] | No | Etiquetas adicionales. |
| `commands` | cadena \| cadena\[] | No | Rutas de acceso a directorios de comandos. |
| `agents` | cadena \| cadena\[] | No | Rutas de acceso a directorios de agentes. |
| `skills` | cadena \| cadena\[] | No | Rutas de acceso a directorios de aptitudes. |
| `hooks` | string \| objeto | No | Ruta a la configuración de hooks u objeto de hooks en línea. |
| `mcpServers` | string \| objeto | No | Servidores MCP que se activarán cuando se instale el complemento. Acepta un mapa de servidores en línea o una ruta a un archivo de configuración JSON. Se usa cuando el origen del complemento no envía su propia configuración de MCP. |
| `lspServers` | string \| objeto | No | Ruta a la configuración de LSP o definiciones de servidor integradas. |
| `strict` | boolean | No | Cuando `true` (el valor predeterminado), los complementos deben ajustarse al esquema completo y a las reglas de validación. Cuando es `false`, se utiliza una validación relajada, se permite más flexibilidad, especialmente para instalaciones directas o complementos heredados. |
#### Tipos de origen del complemento
El campo `source` de una entrada de un complemento acepta una cadena con una ruta relativa o un objeto que describe un repositorio GitHub o un origen con una URL de Git:
```json
{
"source": {
"source": "github",
"repo": "owner/repo",
"ref": "v1.0.0",
"path": "plugins/my-plugin"
}
}
```
Tanto el tipo de origen `github` como el `url` aceptan un campo opcional `sha` para fijar las instalaciones a un commit exacto, además de (o en lugar de) `ref`:
```json
{
"source": {
"source": "github",
"repo": "owner/repo",
"sha": "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
"path": "plugins/my-plugin"
}
}
```
`sha` debe ser un SHA de commit completo de 40 caracteres. Fíjalo a un `sha` para instalaciones reproducibles que sean inmunes a los force-pushes o a los movimientos de etiquetas/ramas.
## Ubicaciones de archivos
| Elemento | Camino |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Complementos instalados | |
| `~/.copilot/installed-plugins/MARKETPLACE/PLUGIN-NAME` (instalado a través de marketplace) y `~/.copilot/installed-plugins/_direct/SOURCE-ID/` (instalado directamente) | |
| Caché de Marketplace | Directorio de caché de plataforma: `~/.cache/copilot/marketplaces/` (Linux), `~/Library/Caches/copilot/marketplaces/` (macOS). Se puede reemplazar con `COPILOT_CACHE_HOME`. |
| Manifiesto del complemento | Complementos del agente (v1.0.0 o v1.1.0): `plugin.json` en la raíz del complemento. Un manifiesto raíz destinado a los Plugins de agente tiene prioridad sobre `.plugin/plugin.json` y `.claude-plugin/plugin.json` según la especificación §5.1. Complementos heredados: `.plugin/plugin.json`, `plugin.json`, `.github/plugin/plugin.json`, o `.claude-plugin/plugin.json` (comprobados en este orden). |
| Manifiesto de Marketplace | |
| `marketplace.json`, `.plugin/marketplace.json`, `.github/plugin/marketplace.json` o `.claude-plugin/marketplace.json` (comprobado en este orden) | |
| Agentes | Complementos heredados: `agents/` (valor predeterminado, reemplazable en el manifiesto). |
| Habilidades | Complementos del agente: `skills/` (fijo, sin reserva raíz `SKILL.md` ). Complementos heredados: `skills/` (valor predeterminado, reemplazable en el manifiesto), volviendo a una raíz `SKILL.md` cuando no existe ningún `skills/` directorio. |
| Configuración de hooks | Complementos heredados: `hooks.json` o `hooks/hooks.json`. |
| Configuración de MCP | Complementos del agente: `mcp.json`. Complementos heredados: `.mcp.json`, `.github/mcp.json`, o el campo de manifiesto `mcpServers`. |
| Configuración de LSP | Complementos heredados: `lsp.json` o `.github/lsp.json`. |
| Datos del complemento | Para los servidores MCP de Agent Plugins 1.0, `${PLUGIN_DATA}` (también disponible como `${COPILOT_PLUGIN_DATA}` y `${CLAUDE_PLUGIN_DATA}`) apunta a un directorio persistente y escribible, único para cada complemento instalado. Use esto para los datos de tiempo de ejecución específicos del complemento en lugar de las rutas dentro del directorio de caché installed-plugins. |
## Orden de carga y prioridad
Si instala varios complementos, es posible que algunos agentes personalizados, aptitudes, servidores MCP o herramientas proporcionados a través de servidores MCP tengan nombres duplicados. En esta situación, la CLI determina qué componente usar en función de un orden de precedencia.
* **Los agentes y las aptitudes** utilizan la prioridad de "primero en encontrar, primero en ganar."
Si tiene un agente personalizado de nivel de proyecto o una aptitud con el mismo nombre o identificador que uno en un complemento que instale, el agente o la aptitud del complemento se omiten silenciosamente. El complemento no puede invalidar configuraciones personales o de nivel de proyecto. Los agentes personalizados se desduplican mediante su identificador, que se deriva de su nombre de archivo (por ejemplo, si el archivo se denomina `reviewer.agent.md`, el identificador del agente es `reviewer`). Las aptitudes se desduplican por su campo de nombre dentro del archivo `SKILL.md`.
* **Los servidores MCP** usan precedencia de última instancia.
Si instala un complemento que define un servidor MCP con el mismo nombre de servidor que un servidor MCP que ya ha instalado, la definición del complemento tiene prioridad. Puede usar la `--additional-mcp-config` opción de línea de comandos para invalidar una configuración del servidor MCP con el mismo nombre, instalada mediante un complemento. Si dos o más complementos declaran un servidor MCP con el mismo nombre, la CLI usa la versión del complemento que cargó por última vez y muestra una advertencia que asigna un nombre a cada complemento anterior que lo definió.
* **Las herramientas y agentes integrados** siempre están presentes y no se pueden invalidar mediante componentes definidos por el usuario.
En el diagrama siguiente se muestran las reglas de orden de carga y precedencia.
```text
┌──────────────────────────────────────────────────────────────────┐
│ BUILT-IN - HARDCODED, ALWAYS PRESENT │
│ • tools: bash, view, apply_patch, glob, rg, task, ... │
│ • agents: explore, task, code-review, general-purpose, research │
└────────────────────────┬─────────────────────────────────────────┘
│
┌──────────────────────▼──────────────────────────────────────────────┐
│ CUSTOM AGENTS - FIRST LOADED IS USED (dedup by ID) │
│ 1. ~/.copilot/agents/ (user, .github convention) │
│ 2. /.github/agents/ (project) │
│ 3. /.github/agents/ (inherited, monorepo) │
│ 4. /.claude/agents/ (project) │
│ 5. /.claude/agents/ (inherited, monorepo) │
│ 6. /.github/agents/ (added root, --add-dir) │
│ 7. PLUGIN: agents/ dirs (plugin, by install order) │
│ 8. Remote org/enterprise agents (remote, via API) │
└──────────────────────┬──────────────────────────────────────────────┘
│
┌──────────────────────▼──────────────────────────────────────────────┐
│ AGENT SKILLS - FIRST LOADED IS USED (dedup by name) │
│ 1. /.github/skills/ (project) │
│ 2. /.agents/skills/ (project) │
│ 3. /.claude/skills/ (project) │
│ 4. /.github/skills/ etc. (inherited) │
│ 5. ~/.copilot/skills/ (personal-copilot) │
│ 6. ~/.agents/skills/ (personal-agents) │
│ 7. PLUGIN: skills/ dirs (plugin) │
│ 8. COPILOT_SKILLS_DIRS env + config (custom) │
│ --- then commands (.claude/commands/), skills override commands ---│
└──────────────────────┬──────────────────────────────────────────────┘
│
┌──────────────────────▼──────────────────────────────────────────────┐
│ MCP SERVERS - LAST LOADED IS USED (dedup by server name) │
│ 1. ~/.copilot/mcp-config.json (lowest priority) │
│ 2. PLUGIN: MCP configs (plugins) │
│ 3. --additional-mcp-config flag (highest priority) │
└─────────────────────────────────────────────────────────────────────┘
```
## Lectura adicional
* [Acerca de los estándares de complementos administrados por la empresa](/es/copilot/concepts/enterprise/plugin-standards)
* [GitHub Copilot CLI](/es/copilot/how-tos/copilot-cli)
* [Referencia de comandos de la CLI de GitHub Copilot](/es/copilot/reference/copilot-cli-reference/cli-command-reference)
* [Referencia programática de la CLI de GitHub Copilot](/es/copilot/reference/copilot-cli-reference/cli-programmatic-reference)