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

Instalación: skills.sh, Claude Code, Codex y Antigravity

6 de agosto de 2026 Por: Artiko

agent-skillsplugins-de-agentesia-agentesgoogle-cloudinstalacionmarketplaceclaude-code

Instalación: skills.sh, Claude Code, Codex y Antigravity

El capítulo anterior describió qué es google/skills: un repositorio con 103 archivos SKILL.md bajo skills/, repartidos en skills/cloud/ (89), skills/ads/ (12) y skills/analytics/ (2). Este capítulo responde la pregunta siguiente: cómo consigues que tu agente los use.

El README oficial documenta cuatro rutas de instalación, y hay una quinta que no documenta porque no hace falta: copiar la carpeta. Las cinco terminan en el mismo estado —un directorio con un SKILL.md en un sitio que tu agente escanea— pero no instalan lo mismo. Esa es la trampa principal del capítulo y conviene decirla de entrada:

npx skills add google/skills instala skills del catálogo, los que tú elijas.
Los marketplaces de Claude Code, Codex y Antigravity instalan plugins, y los plugins que este repositorio publica no son los 103 skills: son 16 entradas de Data Cloud que viven en otros repositorios.

Si instalas por marketplace esperando gke-basics o bigquery-basics, no van a aparecer.

El mapa de decisión

flowchart TD
    A["Quiero usar google slash skills"] --> B{"Que quiero instalar"}
    B -->|"Skills del catalogo<br/>los 103 SKILL.md"| C["npx skills add google/skills"]
    B -->|"Plugins de Data Cloud<br/>skills mas servidores MCP"| D{"Que agente uso"}
    D -->|Claude Code| E["claude plugin marketplace add<br/>luego claude plugin install"]
    D -->|Codex| F["codex plugin marketplace add<br/>luego navegador slash plugins"]
    D -->|Antigravity CLI| G["agy plugin install con URL del plugin"]
    B -->|"Mi agente no soporta nada de esto"| H["Copiar el directorio del skill<br/>a la ruta que escanea el agente"]
    C --> I["Directorio con SKILL.md<br/>visible para el agente"]
    E --> I
    F --> I
    G --> I
    H --> I

Camino 1: skills.sh y el selector interactivo

Es el que abre el README, con insignia propia enlazando a https://skills.sh/google/skills. El comando es exactamente uno:

npx skills add google/skills

El README explica en una sola frase qué pasa a continuación:

From the npx install command, you can select the specific skills from this repo to install.

Es decir: el comando no vuelca los 103 skills sobre tu máquina. Abre un selector donde eliges cuáles quieres. Esa distinción importa porque el catálogo completo son 496 archivos y unos 3,9 MB en disco; el peso en disco es irrelevante, pero el peso en el contexto de tu agente no lo es. Cada skill instalado añade su name y su description al catálogo que el agente lee en cada arranque de sesión, y las description de este repositorio son largas: la de google-cloud-storage-basics ocupa catorce líneas de frontmatter.

skills.sh es una herramienta del ecosistema, no parte de la especificación. Lo que hace, en esencia, es automatizar la selección y la copia de directorios. Todo lo que consigue lo puedes conseguir con cp; lo que aporta es el selector, la resolución del repositorio remoto y la actualización posterior.

Qué queda en disco

La especificación de Agent Skills define qué hay dentro de un directorio de skill, no dónde vive ese directorio. Eso lo decide cada cliente. Las rutas que la guía de implementación sugiere, y que los instaladores respetan, son estas:

Ámbito	Ruta	Para qué
Proyecto	`<proyecto>/.agents/skills/`	Interoperable entre clientes
Proyecto	`<proyecto>/.<cliente>/skills/`	Ubicación nativa del cliente
Usuario	`~/.agents/skills/`	Interoperable entre clientes
Usuario	`~/.<cliente>/skills/`	Ubicación nativa del cliente

La regla práctica: si el skill sirve a un repositorio concreto —por ejemplo gke-manifest-generation en el repo donde generas manifiestos— instálalo en ámbito de proyecto y compromételo en git, para que todo el equipo lo tenga. Si te sirve siempre, como gcloud, va en ámbito de usuario.

El detalle completo de ámbitos, precedencias y qué es norma frente a convención está en el curso hermano: Agent Skills.

Cómo se ve un skill ya instalado

Tras la instalación, el skill es una carpeta con su SKILL.md y, si lo tiene, sus subdirectorios. gke-basics queda así:

gke-basics/
├── SKILL.md
└── references/
    ├── cli-reference.md
    ├── client-library-usage.md
    ├── core-concepts.md
    ├── iac-usage.md
    └── mcp-usage.md

No hay compilación, ni manifiesto extra, ni registro. Si esa carpeta está donde el agente mira, el skill existe. Si no, no.

De los 103 skills del catálogo, 41 son solo un SKILL.md sin ningún archivo acompañante —gke-storage, gke-reliability, gcloud o los seis del Well-Architected Framework, entre otros—. Los tres únicos nombres de subcarpeta que aparecen en todo el repositorio son references/, scripts/ y assets/.

Camino 2: el marketplace de Claude Code

El README lo documenta en dos pasos:

claude plugin marketplace add google/skills

claude plugin install <plugin>@google-plugins

El sufijo @google-plugins no es decorativo: es el campo name del manifiesto .claude-plugin/marketplace.json, que empieza así:

{
  "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": [ ]
}

El primer comando registra ese manifiesto como fuente. El segundo instala una entrada concreta de su lista plugins.

Qué hay realmente en ese marketplace

Dieciséis entradas, y ninguna es un skill de skills/cloud/ ni de skills/ads/. El propio README lo dice sin ambigüedad al abrir la sección:

This repo also bundles Google product plugins (Skills + MCP servers) for agent harnesses.

Son plugins de Data Cloud: cada uno empaqueta skills propios y, donde aplica, un servidor MCP. La lista completa del manifiesto:

Plugin	Origen	Versión fijada
`alloydb`	`gemini-cli-extensions/alloydb`	`0.2.0`
`alloydb-omni`	`gemini-cli-extensions/alloydb-omni`	`0.2.1`
`bigtable`	`GoogleCloudPlatform/cloud-bigtable-ecosystem`	`v0.4.0`
`cloud-sql-mysql`	`gemini-cli-extensions/cloud-sql-mysql`	`0.2.0`
`cloud-sql-postgresql`	`gemini-cli-extensions/cloud-sql-postgresql`	`0.4.0`
`cloud-sql-sqlserver`	`gemini-cli-extensions/cloud-sql-sqlserver`	`0.2.0`
`firestore-native`	`gemini-cli-extensions/firestore-native`	`0.3.1`
`data-agent-kit-starter-pack`	`gemini-cli-extensions/data-agent-kit-starter-pack`	`0.6.1`
`google-cloud-storage`	`gemini-cli-extensions/google-cloud-storage`	`1.2.0`
`looker`	`gemini-cli-extensions/looker`	`0.3.5`
`oracledb`	`gemini-cli-extensions/oracledb`	`0.2.3`
`spanner`	`gemini-cli-extensions/spanner`	`0.3.1`
`knowledge-catalog`	`gemini-cli-extensions/knowledge-catalog`	`0.5.2`
`dataproc`	`gemini-cli-extensions/dataproc`	`0.1.0`
`bigquery`	`gemini-cli-extensions/bigquery-data-analytics`	`0.2.1`
`db-context-engineering`	`GoogleCloudPlatform/db-context-enrichment`	`v0.6.0`

Cada entrada apunta a otro repositorio, fijado a una etiqueta de release. google/skills aquí es un índice, no el alojamiento. Instalar spanner con este marketplace descarga gemini-cli-extensions/spanner en su tag 0.3.1; el skill spanner-basics del catálogo, que es otra cosa distinta, sigue viviendo en skills/cloud/spanner-basics/ y se instala con npx skills add.

Un caso concreto de esa duplicidad aparente: google-cloud-storage (plugin, versión 1.2.0, repositorio gemini-cli-extensions/google-cloud-storage) y google-cloud-storage-basics (skill, skills/cloud/google-cloud-storage-basics/, con diez archivos en references/). Nombres parecidos, artefactos distintos, instaladores distintos.

Un ejemplo de instalación concreta:

claude plugin marketplace add google/skills
claude plugin install bigquery@google-plugins

El desglose de qué es un plugin, cómo se estructura un marketplace.json, qué campos admite y cómo se resuelve cada tipo de fuente —este repositorio usa "source": "github" en el manifiesto de Claude Code y "source": "url" en el de .agents/— está en el curso hermano Agent Plugins Spec. El capítulo 11 de este curso, Plugins y marketplace, analiza el manifiesto concreto de Google.

Camino 3: el marketplace de Codex

El README documenta un solo comando y luego remite a la interfaz:

codex plugin marketplace add google/skills

Después, en palabras del propio README: install from the /plugins browser. Es decir, el registro del marketplace se hace por línea de comandos y la selección del plugin concreto se hace dentro de Codex, con el comando /plugins, que abre un navegador de plugins disponibles.

El repositorio apunta ambos harnesses al mismo origen, google/skills, y publica dos manifiestos con el mismo catálogo: .claude-plugin/marketplace.json, la ubicación convencional de Claude Code, con 16 entradas; y .agents/plugins/marketplace.json, la ubicación interoperable que define la Agent Plugins Specification, con 15. Cuál de los dos lee Codex no lo dice el README, pero el inventario que verás en el navegador /plugins es en la práctica el de la tabla anterior. La diferencia frente a Claude Code es de flujo, no de catálogo.

sequenceDiagram
    participant U as Usuario
    participant C as Codex CLI
    participant R as Repo google slash skills
    U->>C: codex plugin marketplace add google/skills
    C->>R: Lee el manifiesto de marketplace
    R-->>C: 16 entradas de plugin con su origen y version
    U->>C: Comando /plugins
    C-->>U: Navegador con las 16 entradas
    U->>C: Selecciona un plugin
    C->>R: Descarga el repositorio origen en su tag
    C-->>U: Plugin instalado con sus skills y su MCP

Camino 4: Antigravity CLI

Antigravity no lee el manifiesto de marketplace. Instala apuntando directamente a la ruta del plugin dentro del repositorio:

agy plugin install https://github.com/google/skills/<plugin-path>

Ese <plugin-path> no es un hueco abstracto: el README.md de plugins/cloud/data-agent-kit/ da los ejemplos reales:

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

Y explica por qué existe este directorio de rutas físicas cuando ya hay un manifiesto:

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.

El árbol de plugins/ es exactamente esto: un README.md y dieciséis directorios que son submódulos de git, cada uno anclado a un tag concreto de su repositorio original.

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

Dos advertencias prácticas sobre este árbol:

Los directorios están vacíos si clonas sin submódulos. El propio README lo dice: “To update the working tree to the pinned versions, run git submodule update --init from the repo root.” Un git clone normal te deja dieciséis carpetas sin contenido.
El nombre del directorio no siempre coincide con el nombre del plugin. En el manifiesto la entrada se llama bigquery, pero el submódulo se llama bigquery-data-analytics; la entrada bigtable corresponde al submódulo cloud-bigtable-ecosystem; la entrada db-context-engineering corresponde a db-context-enrichment. Si vas a usar agy, la ruta que necesitas es la del directorio, no la del nombre en el manifiesto.

Como ya se apuntó en el camino de Codex, el segundo manifiesto —.agents/plugins/marketplace.json, la ubicación que define la Agent Plugins Specification para cualquier harness— no es una copia del de Claude Code. Lista 15 plugins en lugar de 16 —le falta db-context-engineering—, usa "source": "url" con la URL .git completa en lugar de "source": "github" con repo, y añade campos que el manifiesto de Claude no tiene: un bloque interface con displayName, una policy con installation y authentication, y una category propia con valores como Databases, Business Intelligence & Analytics o Data Governance & Management.

Comprobar que el agente descubrió el skill

Instalar y que funcione son cosas distintas. Tres comprobaciones, de la más barata a la más fiable.

1. El archivo está donde toca

ls ~/.agents/skills/
ls .agents/skills/

Y dentro del directorio del skill, que exista el SKILL.md:

cat ~/.agents/skills/gke-basics/SKILL.md | head -12

Deberías ver un frontmatter con name, metadata y description. En este catálogo esos tres campos aparecen en los 103 skills sin excepción. Solo tres skills añaden un campo compatibility (gemini-api, google-ads-api-quickstart, google-ads-api-mcp-setup), dos declaran license: Apache-2.0 y uno solo declara allowed-tools.

2. El nombre del directorio coincide con el campo `name`

Es requisito de la especificación, y este catálogo lo cumple sin fallos: 103 de 103 skills tienen el name del frontmatter idéntico al nombre de su directorio padre. Si al copiar a mano renombras la carpeta, rompes el skill.

basename $(pwd) && grep '^name:' SKILL.md

Ambas salidas deben decir lo mismo.

3. El agente lo nombra

La prueba real. Pide al agente que enumere lo que tiene disponible, o lánzale una tarea que dispare la description. Los skills de Google están escritos para eso: sus description incluyen tanto los disparadores como las exclusiones. La de gke-basics dice, textualmente:

Manages core GKE cluster provisioning, credentials, Autopilot vs Standard selection, and workload deployment. Use when creating GKE clusters, fetching kubectl credentials, configuring Workload Identity, or deciding between Autopilot and Standard modes. Don’t use for specialized GKE networking (use gke-networking), advanced security hardening (use gke-platform-security or gke-workload-security), or cluster upgrades (use gke-upgrades).

Si pides “crea un cluster de GKE en modo Autopilot” y el agente no menciona ese skill, no está instalado o no está en un ámbito que escanee. Si pides “planifica el upgrade de mi cluster” y toma gke-basics en vez de gke-upgrades, el problema es de selección, no de instalación.

Instalar solo un subconjunto

Es lo que deberías hacer casi siempre, y por una razón concreta: el catálogo completo no cabe cómodamente en tu contexto. Los 103 SKILL.md suman 22 217 líneas. El agente no las lee todas —solo carga el cuerpo del skill que decide usar— pero sí lee los 103 pares de name más description para poder decidir, y esas description son deliberadamente largas.

El criterio de recorte más útil es el del trabajo real, no el del producto:

Si trabajas en…	Instala del orden de…	Ejemplos verificados
Cualquier cosa en Google Cloud	1 skill transversal	`gcloud`
Empezar de cero	3 skills de fundamentos	`google-cloud-recipe-auth`, `google-cloud-recipe-onboarding`, `google-cloud-recipe-foundation-builder`
Kubernetes	subconjunto de los 28 skills `gke-`	`gke-basics`, `gke-cluster-creation`, `gke-workload-troubleshooting`
Datos y analítica	subconjunto de datos	`bigquery-basics`, `bigquery-ai-ml`, `bigquery-bigframes`
Publicidad móvil	subconjunto de ads	`google-mobile-ads-get-started`, `google-mobile-ads-banner`, `google-mobile-ads-interstitial`, `google-mobile-ads-rewarded`
Revisión de arquitectura	los seis pilares WAF	`google-cloud-waf-security`, `google-cloud-waf-reliability`, `google-cloud-waf-cost-optimization`, `google-cloud-waf-operational-excellence`, `google-cloud-waf-performance-optimization`, `google-cloud-waf-sustainability`

Los 28 skills cuyo nombre empieza por gke-, por ejemplo, se solapan en tema pero no en función: gke-basics provisiona, gke-upgrades actualiza, gke-cost-analysis responde preguntas de coste sobre exports de facturación en BigQuery, gke-ai-troubleshooting-tpu-vbar-oom diagnostica segfaults de vbar_control_agent en nodos TPU v6e. Instalar los 28 cuando solo despliegas aplicaciones web añade ruido de decisión sin añadir capacidad.

El capítulo 3, Mapa del catálogo, recorre las 12 secciones del README y sirve precisamente para elegir ese subconjunto con criterio.

Actualizar y desinstalar

Aquí el modelo mental es distinto según el camino que hayas usado.

Skills instalados con skills.sh

Un skill instalado es una copia. No hay enlace vivo con el repositorio: si Google corrige gke-manifest-generation, tu copia no cambia sola. Volver a ejecutar npx skills add google/skills y reseleccionar es la forma de traerte la versión nueva.

Desinstalar es igual de directo: borrar el directorio. No hay registro que limpiar ni caché que invalidar.

rm -rf ~/.agents/skills/gke-basics

Con una salvedad importante: los skills del catálogo no llevan versión en el frontmatter salvo excepciones. De los 103, solo 13 declaran metadata.version —google-cloud-storage-basics con v1, ima-sdk-basics con "1.0.0", data-manager-api-setup con 1.0; doce de esos trece están en skills/ads/— y los otros 90 no declaran ninguna. No puedes preguntarle a un skill instalado qué versión es. Si te importa saber de qué commit vino, registra el commit tú, por ejemplo comprometiendo el skill en el repositorio de tu proyecto y anotando el origen en el mensaje.

Plugins instalados por marketplace

Estos sí están versionados, y de forma estricta: cada entrada del manifiesto fija un tag (0.2.0, v0.4.0, 1.2.0). Actualizar significa que Google mueva el puntero en su manifiesto y que tú refresques la fuente del marketplace y reinstales. El README.md de plugins/cloud/data-agent-kit/ documenta el procedimiento del lado del mantenedor:

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>"

Lo relevante para ti como consumidor es la implicación: la versión que instalas no la decide el repositorio del producto, la decide el puntero que google/skills tiene fijado en ese momento.

flowchart LR
    A["Repositorio del producto<br/>por ejemplo spanner"] -->|tag 0.3.1| B["Submodulo en google slash skills"]
    A -->|tag 0.3.1| C["Entrada del manifiesto"]
    B -->|agy plugin install| D["Tu agente"]
    C -->|claude plugin install| D
    C -->|codex slash plugins| D

Camino 5: copiar el directorio a mano

Si tu agente no soporta npx skills add, ni claude plugin, ni codex plugin, ni agy, no estás fuera. El formato es un estándar abierto y la instalación es una operación de sistema de archivos.

git clone https://github.com/google/skills.git
mkdir -p ~/.agents/skills
cp -r skills/cloud/gke-basics ~/.agents/skills/
cp -r skills/cloud/gcloud ~/.agents/skills/

Eso es todo. Funciona porque un skill es, por definición de la especificación, un directorio que contiene un SKILL.md: frontmatter YAML con name y description, y a continuación instrucciones en Markdown. No hay binario, ni paso de compilación, ni registro central obligatorio. La especificación define el contenido de la carpeta; el emplazamiento lo decide el cliente. Por eso cualquier mecanismo que deje la carpeta en su sitio —cp, git clone, un submódulo, un instalador de terceros— produce el mismo resultado.

Tres reglas al copiar a mano:

No renombres el directorio. El name del frontmatter debe coincidir con el nombre de la carpeta.
Copia el directorio completo, no solo el SKILL.md. De los 103 skills, 55 tienen references/, 17 tienen assets/ y 12 tienen scripts/. Las referencias dentro del SKILL.md son rutas relativas a la raíz del skill: si te dejas references/, el agente seguirá el enlace y no encontrará nada. bigquery-ai-ml tiene 16 archivos en references/; agent-platform-alert-configuration tiene 8 referencias y 18 scripts.
Respeta el ámbito. Ámbito de proyecto para lo específico, ámbito de usuario para lo transversal.

Si quieres el detalle de por qué esto funciona —qué es norma y qué es convención en el formato, cómo se resuelve un SKILL.md y qué pasa cuando dos ámbitos definen el mismo name— ese terreno es exactamente el del curso hermano Agent Skills.

Skills de Google que no están en este catálogo

El README cierra con una sección de Additional Google skills: repositorios de skills de Google que no se instalan con npx skills add google/skills porque viven en otra parte.

Skills	Repositorio
Flutter Skills	`https://github.com/flutter/skills`
Dart Skills	`https://github.com/dart-lang/skills`
Advanced Google Cloud Storage Skills	`https://github.com/gemini-cli-extensions/google-cloud-storage`
Agent Development Kit (ADK) Skills	`https://github.com/google/agents-cli`
Firestore Skills	`https://github.com/firebase/agent-skills/tree/main/skills/firebase-firestore`
Genkit Skills	`https://github.com/genkit-ai/skills`

Dos de ellos aparecen también como plugins del marketplace (google-cloud-storage y firestore-native), lo que refuerza la idea: google/skills es un punto de entrada e índice, no el único alojamiento de skills de Google.

Trampas verificables

Tres cosas que descubres solo abriendo el repositorio.

El README marca el repositorio como inestable. El aviso está en la segunda línea del documento: “This repository is under active development.” Los nombres de skill, las secciones del índice y las versiones fijadas de plugins pueden moverse. Cualquier lista que escribas —incluida la de este curso— es una foto de un commit.

Hay referencias a skills que no existen. La description de ima-sdk-basics dice: “Do not use for Dynamic Ad Insertion (DAI), SSAI, or SGAI (use the ima-sdk-dai-basics skill instead)”. Ese ima-sdk-dai-basics no está en skills/ads/. Y no es un caso aislado: son cuatro las descripciones que redirigen a un nombre inexistente —las otras tres apuntan a vertex-deploy, gma-android-integrate y cloud-monitoring-promql-query—. Es la demostración práctica de por qué conviene comprobar con ls cualquier nombre de skill antes de darlo por instalable.

No puedes contribuir con un pull request. El CONTRIBUTING.md es tajante: “At this time, we are not accepting external pull requests or code contributions.” Lo que sí aceptan son issues y peticiones de skills nuevos, y lo que sí te autorizan explícitamente es a hacer fork y remezclar: “You are encouraged to fork this repository and remix these skills for your own specialized workflows.” La licencia es Apache 2.0. Esto se desarrolla en el capítulo 12, Integrarlos en tu flujo y contribuir.

Resumen

El README de google/skills documenta cuatro instaladores, y los cuatro no instalan lo mismo: npx skills add google/skills instala skills del catálogo; los marketplaces de Claude Code, Codex y Antigravity instalan los 16 plugins de Data Cloud, que viven en otros repositorios.
npx skills add google/skills abre un selector para elegir skills concretos: “you can select the specific skills from this repo to install”. No vuelca los 103.
Claude Code va en dos pasos: claude plugin marketplace add google/skills y luego claude plugin install <plugin>@google-plugins. El sufijo google-plugins es el name del manifiesto .claude-plugin/marketplace.json.
Codex registra la fuente con codex plugin marketplace add google/skills y elige el plugin desde el navegador /plugins. Consume el mismo manifiesto que Claude Code.
Antigravity CLI no lee manifiesto: agy plugin install https://github.com/google/skills/<plugin-path>, con la ruta física del submódulo bajo plugins/cloud/data-agent-kit/. Cuidado: el nombre del directorio no siempre coincide con el nombre del plugin en el manifiesto.
Un skill instalado es un directorio con SKILL.md en un ámbito que el agente escanea: .agents/skills/ o el directorio nativo del cliente, en proyecto o en usuario.
Comprobar la instalación tiene tres niveles: que el archivo esté, que el nombre del directorio coincida con el name del frontmatter, y que el agente lo nombre ante una tarea que dispare su description.
Instala subconjuntos. Los 103 SKILL.md suman 22 217 líneas y las description de este catálogo son largas: cada skill instalado ocupa presupuesto de decisión en cada arranque de sesión.
Actualizar un skill es reinstalarlo; desinstalarlo es rm -rf de su carpeta. Los plugins sí están versionados por tag y su versión la fija el puntero de google/skills.
Si tu agente no soporta ningún instalador, copia el directorio completo. Funciona porque el formato es un estándar abierto: la especificación define qué hay dentro de la carpeta, no dónde vive.

Siguiente: Mapa del catálogo: qué hay y cómo encontrarlo

Instalación: skills.sh, Claude Code, Codex y Antigravity

Instalación: skills.sh, Claude Code, Codex y Antigravity

El mapa de decisión

Camino 1: skills.sh y el selector interactivo

Qué queda en disco

Cómo se ve un skill ya instalado

Camino 2: el marketplace de Claude Code

Qué hay realmente en ese marketplace

Camino 3: el marketplace de Codex

Camino 4: Antigravity CLI

Comprobar que el agente descubrió el skill

1. El archivo está donde toca

2. El nombre del directorio coincide con el campo name

3. El agente lo nombra

Instalar solo un subconjunto

Actualizar y desinstalar

Skills instalados con skills.sh

Plugins instalados por marketplace

Camino 5: copiar el directorio a mano

Skills de Google que no están en este catálogo

Trampas verificables

Resumen

2. El nombre del directorio coincide con el campo `name`