Siempre Listo Escuela
← Volver al listado de tecnologías ← Índice de Google Skills

Plugins y marketplace: cómo Google empaqueta y distribuye

Por: Artiko
agent-skillsplugins-de-agentesia-agentesgoogle-cloudmarketplacemcpgit-submodules

Plugins y marketplace: cómo Google empaqueta y distribuye

Los diez capítulos anteriores recorrieron los 103 SKILL.md del catálogo. Este capítulo trata de la otra mitad del repositorio: los archivos que no enseñan nada al agente, sino que le dicen a un harness de dónde bajar cosas y en qué versión.

Son cuatro piezas, todas en la raíz o cerca de ella:

  • .claude-plugin/marketplace.json — el manifiesto que consumen Claude Code y Codex.
  • .agents/plugins/marketplace.json — un manifiesto paralelo, con otro esquema, para harnesses genéricos.
  • plugins/cloud/data-agent-kit/ — un directorio con 16 submódulos de git y un README.md.
  • .gitmodules — los punteros de esos 16 submódulos.

Y hay un hallazgo que conviene adelantar, porque reordena todo lo demás: en el clon del repositorio no existe ni un solo plugin.json ni un solo mcp.json. Verificado con find . -name "plugin.json" -o -name "mcp.json": cero resultados fuera de .git/. google/skills no contiene plugins. Contiene punteros a plugins que viven en otros repositorios.

Recordatorio del propio README: “This repository is under active development”. Las versiones pinneadas y la forma de los manifiestos que se documentan aquí son las del clon analizado y cambian con frecuencia.

Dos artefactos que se confunden: skill y plugin

Antes de abrir ningún JSON, hay que separar dos cosas que el repositorio mezcla en un mismo árbol.

Un skill es un directorio con un SKILL.md. Se instala con npx skills add google/skills, y lo único que aporta es texto: instrucciones, references/, scripts/, assets/. No arranca procesos ni abre conexiones.

Un plugin es un paquete distribuible que puede traer skills y además servidores MCP. El README.md del directorio de plugins lo dice literal: “These plugins package product-specific Skills and (where applicable) MCP servers for their product’s common user journeys.”

flowchart TB
    subgraph repo["repositorio google/skills"]
        S["skills/ - 103 SKILL.md<br/>contenido real, versionado aqui"]
        M1[".claude-plugin/marketplace.json<br/>16 punteros"]
        M2[".agents/plugins/marketplace.json<br/>15 punteros"]
        G[".gitmodules<br/>16 submodulos"]
        P["plugins/cloud/data-agent-kit/<br/>16 directorios vacios + README"]
    end
    UP["repos upstream<br/>gemini-cli-extensions y GoogleCloudPlatform<br/>aqui viven los plugin.json y mcp.json reales"]
    M1 --> UP
    M2 --> UP
    G --> P
    P -.-> UP

El catálogo de skills es contenido. El bloque de plugins es distribución. Son dos mecanismos independientes que conviven en el mismo repositorio y se instalan con comandos distintos.

.claude-plugin/marketplace.json campo por campo

157 líneas. La estructura de nivel superior tiene cuatro claves:

{
  "name": "google-plugins",
  "owner": {
    "name": "Google LLC"
  },
  "metadata": {
    "version": "0.0.1",
    "description": "A central repository of official skills and prescriptive plugins designed to provide a high-performance experience for building and deploying agentic applications across Google products and technologies."
  },
  "plugins": [ ]
}

Cada campo hace una cosa concreta:

  • name: "google-plugins" — es el identificador del marketplace, no del repositorio. Es exactamente el sufijo que se escribe al instalar: claude plugin install <plugin>@google-plugins. Si este valor cambiara, cambiarían todos los comandos de instalación documentados.
  • owner.name — atribución. "Google LLC", sin email ni url.
  • metadata.version: "0.0.1" — versión del catálogo, no de los plugins. Sigue en 0.0.1 mientras los plugins que indexa van por 1.2.0, 0.6.1 o v0.4.0. Es un número de catálogo, no un contrato.
  • metadata.description — el texto que un harness muestra al listar marketplaces disponibles.
  • plugins — el array, con 16 entradas.

Anatomía de una entrada

La forma estándar, textual del archivo:

{
  "name": "alloydb",
  "source": {
    "source": "github",
    "repo": "gemini-cli-extensions/alloydb",
    "ref": "0.2.0"
  },
  "description": "Create, connect, and interact with an AlloyDB for PostgreSQL database and data."
}

Tres campos por entrada: name, source, description. El objeto source tiene a su vez una clave source anidada que declara el método de obtención, y luego los campos que ese método exige. En el caso "github": repo en formato org/repo y ref con la etiqueta de release.

Nótese lo que no hay: ni version del plugin, ni license, ni keywords, ni category. El manifiesto es deliberadamente delgado; toda esa metadata vive en el plugin.json del repositorio de destino.

Las 16 entradas

namesource.repo o urlrefmétodo
alloydbgemini-cli-extensions/alloydb0.2.0github
alloydb-omnigemini-cli-extensions/alloydb-omni0.2.1github
bigtableGoogleCloudPlatform/cloud-bigtable-ecosystemv0.4.0github
cloud-sql-mysqlgemini-cli-extensions/cloud-sql-mysql0.2.0github
cloud-sql-postgresqlgemini-cli-extensions/cloud-sql-postgresql0.4.0github
cloud-sql-sqlservergemini-cli-extensions/cloud-sql-sqlserver0.2.0github
firestore-nativegemini-cli-extensions/firestore-native0.3.1github
data-agent-kit-starter-packgemini-cli-extensions/data-agent-kit-starter-pack0.6.1github
google-cloud-storagegemini-cli-extensions/google-cloud-storage1.2.0github
lookergemini-cli-extensions/looker0.3.5github
oracledbgemini-cli-extensions/oracledb0.2.3github
spannergemini-cli-extensions/spanner0.3.1github
knowledge-cataloggemini-cli-extensions/knowledge-catalog0.5.2github
dataprocgemini-cli-extensions/dataproc0.1.0github
bigquerygemini-cli-extensions/bigquery-data-analytics0.2.1github
db-context-engineeringGoogleCloudPlatform/db-context-enrichmentv0.6.0git-subdir

Dos observaciones que se pierden si se lee el archivo en diagonal:

El nombre del plugin no siempre es el nombre del repositorio. Tres casos: bigtable viene de cloud-bigtable-ecosystem, bigquery de bigquery-data-analytics, y db-context-engineering de db-context-enrichment. El manifiesto está renombrando para el usuario final. Si buscas el repo por el nombre del plugin, no lo encuentras.

Las etiquetas no tienen formato uniforme. La mayoría usa 0.2.0 sin prefijo; los dos repositorios bajo la organización GoogleCloudPlatform usan v0.4.0 y v0.6.0 con v. El manifiesto no normaliza: copia la etiqueta tal cual la publica cada upstream.

La excepción: git-subdir

La última entrada es la única que rompe la forma:

{
  "name": "db-context-engineering",
  "source": {
    "source": "git-subdir",
    "url": "GoogleCloudPlatform/db-context-enrichment",
    "path": "plugin",
    "ref": "v0.6.0"
  },
  "description": "Context Engineering Agent for generating and maintaining QueryData / Conversational Analytics API context sets (templates, facets, value searches) for natural language to SQL tasks. Works with AlloyDB, Cloud SQL for MySQL, Cloud SQL for PostgreSQL, and Spanner."
}

Tres diferencias respecto de las otras quince: source.source es "git-subdir" en vez de "github", la clave se llama url en vez de repo, y aparece un campo path.

El motivo es estructural. Los quince repositorios de gemini-cli-extensions son el plugin: su raíz es la raíz del paquete. db-context-enrichment es un repositorio de proyecto en el que el plugin es solo un subdirectorio llamado plugin/. git-subdir existe para poder apuntar dentro de un repositorio sin exigir que el upstream se reorganice.

Es un detalle menor y muy revelador: el formato del marketplace tuvo que crecer un método de obtención adicional el día que alguien quiso publicar un plugin que no vivía en la raíz de su repo.

El manifiesto paralelo: .agents/plugins/marketplace.json

El directorio .agents/ contiene un solo archivo: plugins/marketplace.json, de 218 líneas. Mismo name: "google-plugins", esquema distinto:

{
  "name": "google-plugins",
  "interface": {
    "displayName": "Google Plugins"
  },
  "plugins": [ ]
}

Y una entrada tipo:

{
  "name": "alloydb",
  "source": {
    "source": "url",
    "url": "https://github.com/gemini-cli-extensions/alloydb.git",
    "ref": "0.2.0"
  },
  "description": "Create, connect, and interact with an AlloyDB for PostgreSQL database and data.",
  "policy": {
    "installation": "AVAILABLE",
    "authentication": "ON_INSTALL"
  },
  "category": "Databases"
}

Comparación directa de los dos manifiestos:

Aspecto.claude-plugin/marketplace.json.agents/plugins/marketplace.json
Metadatos del catálogoowner.name, metadata.version, metadata.descriptioninterface.displayName
Nº de plugins1615
Plugin ausente—falta db-context-engineering
Forma de sourcesource: "github" + repo + refsource: "url" + url completa con .git + ref
Campos extra por entradaningunopolicy y category

Los dos campos extra merecen atención porque no tienen equivalente en el otro archivo.

policy es idéntico en las quince entradas: installation: "AVAILABLE" y authentication: "ON_INSTALL". Declara que el plugin se puede instalar y que el harness debe disparar el flujo de autenticación en el momento de instalar, no al primer uso. Tiene sentido para plugins de bases de datos: sin credenciales, un servidor MCP de Spanner no puede ni listar instancias.

category introduce una tercera taxonomía en el mismo repositorio, distinta de la del README y distinta de la de metadata.category de los skills que vimos en el capítulo 3:

categoryPlugins
Databasesalloydb, alloydb-omni, bigtable, cloud-sql-mysql, cloud-sql-postgresql, cloud-sql-sqlserver, firestore-native, data-agent-kit-starter-pack, oracledb, spanner
Storagegoogle-cloud-storage
Business Intelligence & Analyticslooker
Data Governance & Managementknowledge-catalog
Data Processing & ETLdataproc
Data Warehousing & Data Lakesbigquery

Ninguna de estas etiquetas aparece en el frontmatter de ningún skill. Son categorías de producto de datos, con espacios y ampersands, pensadas para pintar una interfaz de navegación.

Un último detalle sobre .agents/: el .gitignore del repositorio incluye la línea .agents/cache/ bajo el comentario # Agent / skill local artifacts. Es decir, .agents/ no es solo un directorio de manifiestos versionados: se espera que los harnesses escriban estado local ahí y que ese estado no se comitee.

plugins/cloud/data-agent-kit/: un directorio de dieciséis huecos

Este es el árbol real, tal cual sale de un clon sin inicializar submódulos:

plugins/cloud/data-agent-kit/
├── README.md                        <-- unico archivo real
├── alloydb/                         (submodulo, vacio)
├── alloydb-omni/                    (submodulo, vacio)
├── bigquery-data-analytics/         (submodulo, vacio)
├── cloud-bigtable-ecosystem/        (submodulo, vacio)
├── cloud-sql-mysql/                 (submodulo, vacio)
├── cloud-sql-postgresql/            (submodulo, vacio)
├── cloud-sql-sqlserver/             (submodulo, vacio)
├── data-agent-kit-starter-pack/     (submodulo, vacio)
├── dataproc/                        (submodulo, vacio)
├── db-context-enrichment/           (submodulo, vacio)
├── firestore-native/                (submodulo, vacio)
├── google-cloud-storage/            (submodulo, vacio)
├── knowledge-catalog/               (submodulo, vacio)
├── looker/                          (submodulo, vacio)
├── oracledb/                        (submodulo, vacio)
└── spanner/                         (submodulo, vacio)

find plugins -type f devuelve un archivo: el README.md. Los 16 directorios están vacíos hasta que se ejecuta git submodule update --init desde la raíz. Y aun después de materializarlos, sus plugin.json y mcp.json pertenecen al repositorio de origen, no a google/skills.

El propio README.md lo declara sin ambigüedad:

“This directory vendors the Google Data Cloud plugins as git submodules, so they can be discovered and installed through the central google/skills repository. Each submodule pins to a specific release tag of its upstream plugin repository, which remains the source of truth for that plugin’s skills and MCP server definition.”

Es decir: aquí no hay configuración MCP. La hay en cada upstream. Este directorio es un índice de versiones, no un paquete.

Por qué submódulos y no solo el manifiesto

La justificación está escrita, y es puramente táctica:

“Submodules are used here because Antigravity CLI does not yet support a marketplace manifest (as Claude Code and Codex do). Once marketplace support lands for agy, these submodules can be retired in favor of the shared manifest.”

Antigravity CLI instala apuntando a una ruta de repositorio, no a una entrada de catálogo:

agy plugin install https://github.com/google/skills/plugins/cloud/data-agent-kit/alloydb
agy plugin install https://github.com/google/skills/plugins/cloud/data-agent-kit/spanner

Para que esa URL resuelva a algo, el directorio tiene que existir en el árbol de google/skills. De ahí los submódulos: son el adaptador que permite que un cliente sin soporte de marketplace instale desde el mismo repositorio central. El README los marca explícitamente como deuda temporal, retirable el día que agy soporte manifiestos.

.gitmodules: 16 submódulos y un abuso deliberado de branch

[submodule "alloydb"]
	path = plugins/cloud/data-agent-kit/alloydb
	url = https://github.com/gemini-cli-extensions/alloydb
	branch = 0.2.0

[submodule "alloydb-omni"]
	path = plugins/cloud/data-agent-kit/alloydb-omni
	url = https://github.com/gemini-cli-extensions/alloydb-omni
	branch = 0.2.1

Los 16 bloques tienen path bajo plugins/cloud/data-agent-kit/ y usan la clave branch para guardar una etiqueta de release, no una rama. Es una convención habitual: branch es lo que lee git submodule update --remote, y ponerle un tag inmoviliza el submódulo en esa versión en vez de seguir la cabecera móvil de una rama.

Dos nombres de submódulo no coinciden con el nombre del plugin en el marketplace, por la misma razón que ya vimos: el submódulo se llama como el repositorio (bigquery-data-analytics, cloud-bigtable-ecosystem, db-context-enrichment), el plugin se llama como el producto (bigquery, bigtable, db-context-engineering).

Tres copias de la misma matriz de versiones

Aquí está la consecuencia operativa de todo lo anterior. La versión de cada plugin está escrita en tres sitios distintos, sincronizados a mano:

flowchart LR
    V["version de un plugin<br/>ejemplo alloydb 0.2.0"]
    A[".gitmodules<br/>branch = 0.2.0"]
    B[".claude-plugin/marketplace.json<br/>ref 0.2.0"]
    C["plugins/cloud/data-agent-kit/README.md<br/>columna Version"]
    D[".agents/plugins/marketplace.json<br/>ref 0.2.0"]
    V --> A
    V --> B
    V --> C
    V --> D

En el clon analizado las 16 versiones de .gitmodules coinciden exactamente con los ref de .claude-plugin/marketplace.json y con la columna Version de la tabla del README. La cuarta copia, .agents/plugins/marketplace.json, coincide en los 15 plugins que sí lista.

El README documenta el procedimiento de subida de versión, que toca dos de esos sitios:

cd plugins/cloud/data-agent-kit/<plugin>
git fetch --tags
git checkout <new-version>
cd -
git config -f .gitmodules submodule.<plugin>.branch <new-version>
git add .gitmodules plugins/cloud/data-agent-kit/<plugin>
git commit -m "feat(<plugin>): bump to <new-version>"

Los otros dos —los dos marketplace.json y la tabla del README— quedan fuera del procedimiento escrito. Es exactamente el tipo de duplicación que se desincroniza sola; conviene comprobar el ref real antes de fiarse de la tabla de un README.

Cómo se instala desde cada harness

Los comandos exactos, tal como los publica el README.md de la raíz:

Agent harnessInstalación
Claude Codeclaude plugin marketplace add google/skills, y luego claude plugin install <plugin>@google-plugins
Codexcodex plugin marketplace add google/skills, y luego instalar desde el navegador /plugins
Antigravity CLIagy plugin install https://github.com/google/skills/<plugin-path>

Y aparte, para los skills sueltos —que es otro mecanismo distinto, visto en el capítulo 2:

npx skills add google/skills
flowchart TB
    U["quieres instalar algo de google/skills"]
    Q1{"skill suelto<br/>o plugin de producto de datos"}
    U --> Q1
    Q1 -->|skill| SK["npx skills add google/skills<br/>y eliges de la lista"]
    Q1 -->|plugin| Q2{"que harness usas"}
    Q2 -->|Claude Code| CC["claude plugin marketplace add<br/>luego claude plugin install"]
    Q2 -->|Codex| CX["codex plugin marketplace add<br/>luego navegador /plugins"]
    Q2 -->|Antigravity| AG["agy plugin install<br/>con la URL del subdirectorio"]
    CC --> R["el harness clona el repo upstream en el ref pinneado"]
    CX --> R
    AG --> R

Fíjate en el final del diagrama: en los tres caminos de plugin, lo que acaba en tu máquina no es código de google/skills, sino un clon del repositorio upstream en la etiqueta que el manifiesto declaró.

Dónde termina el estándar y empieza la convención de producto

Esta es la parte donde conviene ser preciso, porque es fácil confundir lo que define la Agent Plugins Specification 1.0.0 con lo que Google decidió por su cuenta.

Lo tratamos en detalle en el curso hermano Agent Plugins Spec, pero resumido: APS 1.0.0 es una especificación de formato de paquete. Define exactamente esto:

  • Un plugin es un directorio con un manifiesto obligatorio en plugin.json en la raíz.
  • El manifiesto tiene un esquema cerrado: solo $schema, name, version, description, author, homepage, repository, license, keywords y extensions. Cualquier otro campo de nivel superior debe reportarse e ignorarse.
  • Hay exactamente dos tipos de componente: skills y servidores MCP.
  • Sus ubicaciones son fijas y plugin.json no puede cambiarlas: los skills en skills/ (cada subdirectorio inmediato con un SKILL.md, sin búsqueda recursiva más profunda), los servidores MCP en mcp.json en la raíz.
  • Los skills deben ajustarse a la Agent Skills specification. La spec de plugins define cómo se descubren, no cómo se escriben; eso es el territorio del curso Agent Skills.
  • Los datos específicos de cada cliente van bajo extensions, con claves en notación de dominio inverso, y sus archivos en un directorio de nivel superior con ese mismo nombre.
  • Un cliente que lanza subprocesos debe proveer PLUGIN_ROOT y PLUGIN_DATA y expandir esos dos marcadores en args, env y cwd.

Ahora, la lista de lo que APS 1.0.0 no define. Es corta y es la clave del capítulo:

No define marketplaces. La palabra marketplace no aparece ni una vez en el texto de la especificación 1.0.0. Ni catálogos, ni índices, ni un formato de descubrimiento remoto. La spec empieza en “un plugin es un directorio en el sistema de archivos” y termina ahí; cómo llega ese directorio a tu disco queda completamente fuera de alcance.

De modo que:

Artefacto¿Estándar APS?Qué es realmente
plugin.jsonSí, normativo, obligatorioManifiesto del paquete
skills/<nombre>/SKILL.mdSí, ubicación fijaComponente skill
mcp.jsonSí, ubicación fijaComponente servidor MCP
.claude-plugin/marketplace.jsonNoConvención de producto de Claude Code y Codex
.agents/plugins/marketplace.jsonNoConvención de otro harness
policy y category en las entradasNoCampos propios del segundo manifiesto
Submódulos en plugins/cloud/data-agent-kit/NoTruco de fontanería para Antigravity CLI

Esto explica sin misterio por qué google/skills no tiene ningún plugin.json: no es un plugin. Es un catálogo de distribución. Los paquetes conformes a APS son los dieciséis repositorios de destino, cada uno con su plugin.json, sus skills/ y —donde aplique— su mcp.json.

Hay un guiño de nomenclatura que vale la pena señalar sin sobreinterpretarlo. La especificación, al ilustrar PLUGIN_ROOT y PLUGIN_DATA, usa este ejemplo:

PLUGIN_ROOT=/home/alex/.agents/plugins/devtools
PLUGIN_DATA=/home/alex/.agents/plugins/data/devtools

Es la misma ruta .agents/plugins/ que usa el repositorio de Google. En la spec es un ejemplo no normativo de dónde un cliente podría instalar plugins en el HOME del usuario; en google/skills es un directorio versionado en la raíz del repositorio con un manifiesto dentro. Coincide la convención de nombre, no el rol. Confundir ambas cosas es el error clásico al leer este repositorio.

Cómo se complementan

Nada de esto es una crítica al diseño de Google: el hueco de la spec es real y alguien tenía que rellenarlo.

flowchart TB
    APS["Agent Plugins Specification 1.0.0<br/>define el formato del paquete"]
    GAP["hueco: no define distribucion ni descubrimiento"]
    MP["convenciones de marketplace<br/>una por harness"]
    PKG["paquetes conformes<br/>plugin.json + skills/ + mcp.json"]
    APS --> PKG
    APS --> GAP
    GAP --> MP
    MP --> PKG

El marketplace resuelve cuál paquete y en qué versión. La spec resuelve qué hay dentro de ese paquete y cómo cargarlo. Que hoy hagan falta dos manifiestos con esquemas distintos para el mismo conjunto de plugins es la medida exacta de lo que aún no está estandarizado.

El solapamiento entre skills y plugins

Vale la pena mirar dónde se cruzan las dos mitades del repositorio, porque hay productos que aparecen en ambas.

En el catálogo de skills existen, verificados en skills/cloud/: alloydb-basics, bigquery-basics, bigquery-ai-ml, bigquery-bigframes, bigtable-basics, cloud-sql-basics, spanner-basics y google-cloud-storage-basics. Todos ellos tienen además un plugin homónimo en el marketplace (alloydb, bigquery, bigtable, cloud-sql-*, spanner, google-cloud-storage).

La diferencia práctica: el skill bigquery-basics te da conocimiento y comandos bq/gcloud; el plugin bigquery te da además, si el upstream lo trae, un servidor MCP con herramientas tipadas contra la API. Uno instruye, el otro conecta. Los revisamos por separado en el capítulo 9.

Y hay productos que solo existen como plugin: looker, dataproc, knowledge-catalog, firestore-native, oracledb. Ninguno tiene un skill propio en skills/cloud/ —verificable con ls skills/cloud | grep -Ei "looker|dataproc|firestore|knowledge|oracle", que solo devuelve google-cloud-solution-agentic-analytics-spark-knowledge-catalog, un skill de solución que usa Knowledge Catalog pero no es el plugin del producto.

La dirección contraria también existe. skills/ads/google-ads-api-mcp-setup es un skill del catálogo cuyo trabajo es precisamente instalar un servidor MCP a mano. Su description real:

“Guides developers through downloading, configuring, and installing the official open-source Google Ads MCP Server. Use this skill when a user wants to connect their AI assistant (such as Gemini, Claude Code, or Cursor) to their Google Ads account to query campaigns or retrieve reporting metrics using natural language.”

Es un skill haciendo el trabajo que en el mundo de los plugins haría un mcp.json: instrucciones en prosa para que el agente edite tu configuración, exporte variables como GOOGLE_ADS_DEVELOPER_TOKEN y arranque el servidor. Lo detallamos en el capítulo 10. Es la mejor ilustración de la frontera: cuando no hay plugin empaquetado, el skill suple con texto lo que el formato haría con un archivo.

Qué llevarse a la práctica

Tres cosas concretas si vas a trabajar con este repositorio.

Verifica siempre el ref, no la tabla. Las versiones están duplicadas en cuatro lugares y solo dos entran en el procedimiento documentado de subida. La fuente más fiable es .gitmodules más el ref del marketplace.json; el README es el más propenso a quedarse atrás.

No busques configuración MCP dentro de google/skills. No la hay. Si necesitas saber qué herramientas expone el plugin spanner, hay que ir al mcp.json de gemini-cli-extensions/spanner en la etiqueta 0.3.1.

Y si vas a publicar tu propio catálogo, la lección del repositorio de Google es que el paquete lo estandariza APS y el índice lo decides tú —hoy, una vez por cada harness al que quieras llegar. Cómo empaquetar tus propios skills siguiendo el mismo patrón es el tema del capítulo final.

Resumen

  • google/skills no contiene ningún plugin: no hay un solo plugin.json ni mcp.json en el árbol. Contiene punteros a 16 plugins que viven en repositorios upstream, principalmente bajo gemini-cli-extensions.
  • .claude-plugin/marketplace.json declara name: "google-plugins" —el sufijo literal de claude plugin install <plugin>@google-plugins—, owner.name: "Google LLC", metadata.version: "0.0.1" y 16 entradas de tres campos: name, source y description.
  • Quince entradas usan source: "github" con repo y ref; solo db-context-engineering usa git-subdir con url y path: "plugin", porque su plugin es un subdirectorio de un repositorio mayor.
  • Tres nombres de plugin no coinciden con su repositorio: bigtable, bigquery y db-context-engineering.
  • .agents/plugins/marketplace.json es un manifiesto paralelo con otro esquema: interface.displayName en vez de owner/metadata, source: "url" con la URL .git completa, 15 entradas en vez de 16, y dos campos extra por entrada —policy con installation: "AVAILABLE" y authentication: "ON_INSTALL", y category con una tercera taxonomía distinta a la de los skills.
  • plugins/cloud/data-agent-kit/ tiene un solo archivo real, el README.md; sus 16 directorios son submódulos vacíos hasta git submodule update --init. Existen porque Antigravity CLI aún no soporta manifiestos de marketplace, y el propio README los declara retirables cuando lo soporte.
  • .gitmodules pinnea cada submódulo con branch = <tag>, usando la clave de rama para inmovilizar una etiqueta de release.
  • La Agent Plugins Specification 1.0.0 define plugin.json, la ubicación fija skills/, la ubicación fija mcp.json, el campo extensions y las variables PLUGIN_ROOT y PLUGIN_DATA. No menciona marketplaces ni una sola vez. Todo lo de este capítulo es convención de producto rellenando ese hueco.

Siguiente: Integrarlos en tu flujo y contribuir al catálogo

← Volver al listado de tecnologías ← Índice de Google Skills