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

Integrarlos en tu flujo y contribuir al catálogo

6 de agosto de 2026 Por: Artiko

agent-skillsplugins-de-agentesia-agentesgoogle-cloudgkecloud-runagent-platformobservabilidad

Integrarlos en tu flujo y contribuir al catálogo

Los once capítulos anteriores recorrieron el catálogo pieza por pieza. Este cierra el curso haciendo lo contrario: en vez de mirar skills sueltos, los encadena. Tres flujos completos con los comandos reales y los skills que se activan en cada paso; después, las decisiones prácticas que nadie documenta —cuántos instalar antes de que el agente empiece a elegir mal, cómo conviven con los tuyos, qué se puede fijar a una versión— y al final lo que el repositorio acepta, y lo que no.

Recordatorio del capítulo 1: el README lleva un aviso explícito, This repository is under active development. Todo lo que sigue describe el catálogo tal como está hoy: 103 SKILL.md repartidos en skills/cloud/ con 89, skills/ads/ con 12 y skills/analytics/ con 2.

Flujo A: arrancar un proyecto nuevo en Google Cloud desde cero

El punto de partida más común: una cuenta recién creada, o una organización sin jerarquía de recursos. El README tiene una sección entera para esto, Getting started with Google Cloud, con exactamente tres skills, los tres con metadata.category: GettingStarted. A esos tres hay que sumar gcloud, que no pertenece a la sección —su categoría es CloudInfrastructureAndServices— pero se activa igual en cuanto el agente va a proponer un comando.

Skill	Ruta en el repo	Rol en el flujo
`google-cloud-recipe-onboarding`	`skills/cloud/google-cloud-recipe-onboarding/`	Primeros pasos de un desarrollador individual: cuenta, proyecto, billing
`google-cloud-recipe-auth`	`skills/cloud/google-cloud-recipe-auth/`	Identidades, ADC y autorización
`google-cloud-recipe-foundation-builder`	`skills/cloud/google-cloud-recipe-foundation-builder/`	Landing zone de organización con guardarraíles
`gcloud`	`skills/cloud/gcloud/`	Validación de sintaxis de todo comando `gcloud`

La separación está en la descripción del foundation builder: Don't use for individual project onboarding (use google-cloud-recipe-onboarding or product-specific skills instead). Persona con tarjeta y un proyecto: onboarding. Organización con carpetas, políticas y logging centralizado: foundation builder.

google-cloud-recipe-onboarding no es una lista de pasos: impone un protocolo de interacción. Su [!IMPORTANT] fija cuatro reglas para agentes autónomos, dos decisivas: Check-Before-Mutate Audits, auditar el estado en silencio antes de proponer cambios de proyecto o billing, y Single-Question Policy, preguntar exactamente un parámetro por turno. Además exige --quiet y --format="json" en toda mutación, para salidas deterministas y para que la terminal no se cuelgue esperando una confirmación interactiva.

google-cloud-recipe-foundation-builder provisiona en la raíz de la organización 17 Organization Policies de base como guardarraíles —13 booleanas y 4 de lista—, 4 carpetas Common, Production, Non-Production y Development con proyectos de prefijos logging-, prod-, non-prod- y dev- más un sufijo compartido, la vinculación de todos a la cuenta de facturación, y un log bucket centralizado global con 30 días de retención más un sink de audit logs de organización. Trae org-policies.md, logging-monitoring.md y admin-iam.md en references/, y abre con un [!WARNING]: está en preview.

gcloud se activa sin que lo pidas. Su precondición está en mayúsculas al principio del archivo, MANDATORY PRE-CONDITION: EXPLICIT LEAF-LEVEL SYNTAX VALIDATION, y declara que todo conocimiento previo de gcloud es “stale and prone to hallucination”. En la práctica: el agente ejecuta gcloud help <comando-hoja> antes de proponerte la sintaxis final, y si le pides un plan, el paso 1 de ese plan es la consulta de ayuda al subcomando hoja.

sequenceDiagram
    participant Dev as Desarrollador
    participant Agent as Agente
    participant Onb as google-cloud-recipe-onboarding
    participant Auth as google-cloud-recipe-auth
    participant GC as gcloud
    participant FB as google-cloud-recipe-foundation-builder

    Dev->>Agent: quiero empezar en Google Cloud
    Agent->>Onb: carga por descripcion
    Onb-->>Agent: preambulo mas una sola pregunta por turno
    Agent->>Dev: reusar proyecto existente o crear uno nuevo
    Dev-->>Agent: crear uno nuevo
    Agent->>GC: gcloud help projects create
    GC-->>Agent: sintaxis validada a nivel hoja
    Agent->>Dev: comando con --quiet y --format json
    Agent->>Auth: como autentico la app despues
    Auth-->>Agent: ADC y Workload Identity Federation
    Dev->>Agent: ahora la organizacion completa
    Agent->>FB: 17 politicas mas 4 carpetas mas logging central

gcloud auth login                     # autoriza la estación de trabajo
gcloud help projects create           # validación exigida por el skill gcloud

# Mutaciones con las banderas que impone el skill de onboarding
gcloud projects create MI_PROYECTO --quiet --format="json"
gcloud billing projects link MI_PROYECTO \
    --billing-account=CUENTA_FACTURACION --quiet --format="json"

gcloud auth application-default login # ADC para el código local

google-cloud-recipe-auth es un SKILL.md sin references/, scripts/ ni assets/, como 41 de los 103 skills del catálogo. Ver el capítulo 5.

Flujo B: desplegar un servicio y montar su observabilidad

El segundo flujo asume el proyecto listo: despliegas un servicio y lo dejas observable. Aquí el catálogo obliga a cambiar de familia dos veces, primero infraestructura y después management tools.

Skill	Ruta en el repo	Rol en el flujo
`cloud-run-basics`	`skills/cloud/cloud-run-basics/`	Services, jobs y worker pools
`cloud-logging-configuration-basics`	`skills/cloud/cloud-logging-configuration-basics/`	Buckets, sinks, views y métricas basadas en logs
`cloud-monitoring-metric-selection`	`skills/cloud/cloud-monitoring-metric-selection/`	Descubrir los metric descriptors correctos
`cloud-monitoring-chart-generation`	`skills/cloud/cloud-monitoring-chart-generation/`	Widgets textproto para la Dashboards API
`google-cloud-slo-alert-configuration`	`skills/cloud/google-cloud-slo-alert-configuration/`	Políticas de alerta SLO en Terraform
`cloud-logging-query-generation`	`skills/cloud/cloud-logging-query-generation/`	Consultas LQL desde lenguaje natural
`google-cloud-waf-reliability`	`skills/cloud/google-cloud-waf-reliability/`	Revisión contra el pilar de Reliability

cloud-run-basics distingue tres tipos de recurso desde su # H1: Services para peticiones HTTP con instancias sin estado que autoescalan, Jobs para tareas paralelizables que se ejecutan hasta completarse, y Worker pools para cargas de fondo siempre activas como un consumidor de Kafka o una cola pull de Pub/Sub. Su ## Prerequisites habilita las APIs y lista los roles: roles/run.admin, roles/run.sourceDeveloper, roles/iam.serviceAccountUser y roles/logging.viewer.

En observabilidad la división es más fina de lo que parece. cloud-monitoring-metric-selection solo descubre descriptores, con una regla dura —“Always Query Live APIs”, vía la herramienta MCP list_metric_descriptors— y una prohibición explícita de consultar proyectos placeholder como mock-project, my-project-id o YOUR_PROJECT_ID. cloud-monitoring-chart-generation toma esa PromQL resuelta y produce textprotos google.monitoring.dashboard.v1.Widget; su descripción dice que no sirve para descubrir métricas ni generar PromQL.

google-cloud-slo-alert-configuration es un asistente de cuatro pasos: ServiceScope, Service Level, SLI y condición de alerta. Sus reglas son tajantes: evaluar los cuatro pasos primero y preguntar todo lo que falta en una sola respuesta, y no escribir Terraform si falta información. La salida es siempre .tf con google_monitoring_alert_policy y condition_prometheus_query_language, más un bloque alert_strategy con auto_close.

Si el destino es GKE, el flujo cambia de skills pero no de forma: gke-basics para el cluster, gke-app-onboarding para contenerizar —trae assets/ con Dockerfile, deployment.yaml, index.js y package.json—, gke-manifest-generation para los manifiestos endurecidos, gke-observability para logging y Managed Prometheus, y gke-productionize como orquestador, que se declara meta-skill y debe invocar a otros en lugar de implementarlo todo. El detalle, en el capítulo 8.

sequenceDiagram
    participant Dev as Desarrollador
    participant Agent as Agente
    participant Run as cloud-run-basics
    participant Log as cloud-logging-configuration-basics
    participant Sel as cloud-monitoring-metric-selection
    participant Chart as cloud-monitoring-chart-generation
    participant SLO as google-cloud-slo-alert-configuration
    participant WAF as google-cloud-waf-reliability

    Dev->>Agent: despliega la api y dejala observable
    Agent->>Run: carga por descripcion
    Run-->>Agent: services vs jobs vs worker pools mas roles IAM
    Agent->>Log: configura bucket y sink del proyecto
    Log-->>Agent: tiers de confirmacion para operaciones destructivas
    Agent->>Sel: que metricas expone Cloud Run
    Sel-->>Agent: descriptores traidos de la API en vivo
    Agent->>Chart: convierte la PromQL en widget textproto
    Chart-->>Agent: google.monitoring.dashboard.v1.Widget
    Agent->>SLO: define el objetivo de disponibilidad
    SLO-->>Agent: terraform con alert_policy y auto_close
    Dev->>Agent: revisa esto antes de produccion
    Agent->>WAF: pilar de Reliability
    WAF-->>Agent: recomendaciones y brechas

# Prerrequisito declarado por cloud-run-basics
gcloud services enable run.googleapis.com cloudbuild.googleapis.com --quiet

gcloud run deploy SERVICE_NAME --source . --quiet   # desde código con Dockerfile

# Desde imagen
gcloud run deploy SERVICE_NAME --image IMAGE_URL \
    --region us-central1 --allow-unauthenticated --quiet

# Un job que corre hasta completarse
gcloud run jobs deploy JOB_NAME --image IMAGE_URL --quiet
gcloud run jobs execute JOB_NAME --wait --region=REGION --quiet

Para los logs, cloud-logging-query-generation traduce lo que preguntas a LQL. Es el skill con más references/ del catálogo —22 archivos, uno por servicio, entre ellos query_cloud_run.md y query_gke.md— y el agente carga solo el que corresponde: carga progresiva pura.

Flujo C: una capa de IA con Agent Platform, evaluada con el flywheel

El tercer flujo muestra por qué el catálogo tiene 103 skills en lugar de diez: construir un agente toca diseño, despliegue, evaluación y alerting, y cada etapa tiene el suyo.

Skill	Ruta en el repo	Rol en el flujo
`google-cloud-solution-build-deploy-agents`	`skills/cloud/google-cloud-solution-build-deploy-agents/`	Diseño de la arquitectura agéntica en 4 fases
`google-agents-cli-onboarding`	`skills/cloud/google-agents-cli-onboarding/`	Entrada al ciclo de vida de ADK con `agents-cli`
`agent-platform-deploy`	`skills/cloud/agent-platform-deploy/`	Desplegar modelos de Model Garden a endpoints
`agent-platform-eval-flywheel`	`skills/cloud/agent-platform-eval-flywheel/`	Medir y mejorar calidad con el Quality Flywheel
`agent-platform-alert-configuration`	`skills/cloud/agent-platform-alert-configuration/`	Alertas OTel de latencia, error, tokens y calidad
`agent-platform-troubleshooting`	`skills/cloud/agent-platform-troubleshooting/`	Gateway, Registry, Identity, Policies, Model Armor, IAP

google-cloud-solution-build-deploy-agents pertenece a la familia Multi-product solution skills del capítulo 6: cuatro fases —descubrimiento, diseño, plan de implementación y validación— y tres plantillas en assets/: solution-template.md, implementation-template.md y validation-template.md. El SKILL.md te pide copiar un checklist de cuatro casillas a tu artefacto de plan activo.

google-agents-cli-onboarding es el único skill del catálogo con metadata.category: DevOps, y funciona como puerta de entrada a skills que viven fuera de este repositorio. Su [!TIP] de setup ofrece dos comandos: uvx google-agents-cli setup para instalar la CLI y configurar los skills en tu agente, o npx skills add google/agents-cli para instalar solo los skills expertos y dejar la ejecución al agente. Su tabla reparte ocho fases —de la 0, Understand, a la 7, Observe— entre siete skills especializados, porque google-agents-cli-workflow cubre las dos primeras: google-agents-cli-workflow, google-agents-cli-scaffold, google-agents-cli-adk-code, google-agents-cli-eval, google-agents-cli-deploy, google-agents-cli-publish y google-agents-cli-observability. Ninguno de los siete está en google/skills: viven en https://github.com/google/agents-cli, que el README enlaza en su sección Additional Google skills.

agent-platform-eval-flywheel trae 5 archivos en references/ y 7 en scripts/. Son cinco etapas que se corren en orden la primera vez y después se repiten en bucle de la 2 a la 5 hasta alcanzar el objetivo de calidad: Prepare Data, Run Inference, Grade, Analyze Failures, Optimize and Iterate. Su SKILL.md incluye además una tabla titulada “Shortcuts that waste time” con los atajos que el agente debe rechazar:

Atajo	Por qué falla
Bajar el umbral de la métrica para que pase	Esconde fallos reales. Arregla el agente, no la vara.
Este caso es inestable, lo salto	La inestabilidad revela no determinismo. Se arregla con `temperature=0` o instrucciones más estrictas.
Solo hay que arreglar el dataset, no el agente	Si las salidas esperadas se mueven, el agente tiene un problema de comportamiento.

También corrige dos importaciones plausibles que no funcionan: from agentplatform.types import evals falla con ModuleNotFoundError porque types es un módulo y no un paquete, y from vertexai.evaluation import PointwiseMetric, EvalTask es el SDK superado, cuyas clases toman argumentos distintos y fallan con TypeError.

Sus tiers separan lo gratis de lo caro: Tier R para scripts de solo lectura como inspect_results.py o validate_dataset.py, y Tier M para lo que invoca LLM y consume cómputo —client.evals.run_inference, client.evals.evaluate— que exige confirmación interactiva. agent-platform-alert-configuration añade un Tier B para recursos con facturación, y obliga a advertir del coste extra del Online Monitor, mencionando las evaluaciones LLM, y de la telemetría, mencionando Cloud Trace y Cloud Logging.

sequenceDiagram
    participant Dev as Desarrollador
    participant Agent as Agente
    participant Sol as google-cloud-solution-build-deploy-agents
    participant CLI as google-agents-cli-onboarding
    participant Dep as agent-platform-deploy
    participant Eval as agent-platform-eval-flywheel
    participant Alert as agent-platform-alert-configuration

    Dev->>Agent: quiero un agente de soporte sobre nuestra documentacion
    Agent->>Sol: fases 1 a 3 requisitos arquitectura y plan
    Sol-->>Agent: solution-template mas implementation-template
    Agent->>CLI: scaffold y ciclo de vida ADK
    CLI-->>Agent: siete skills externas de agents-cli
    Agent->>Dep: despliega el modelo abierto elegido
    Dep-->>Agent: tier de confirmacion antes de crear endpoint
    Dev->>Agent: mide la calidad
    Agent->>Eval: etapa 1 preparar dataset
    Eval-->>Agent: validate_dataset.py en tier R
    Agent->>Eval: etapa 3 grade con confirmacion de coste
    Eval-->>Agent: veredictos por rubrica y scores
    Agent->>Eval: etapas 4 y 5 analizar y optimizar
    Eval-->>Agent: compare_results.py detecta regresiones
    Agent->>Alert: alertas OTel del agente ya desplegado
    Alert-->>Agent: advertencia explicita de coste antes de provisionar

# Ciclo de vida ADK, según google-agents-cli-onboarding
uvx google-agents-cli setup
agents-cli scaffold mi-agente
agents-cli eval run
agents-cli deploy
agents-cli publish gemini-enterprise

# Dependencias del flywheel: probar antes de instalar, sin crear venv
python3 -c "import vertexai, google.genai, pandas, requests" \
  || pip install 'google-cloud-aiplatform[evaluation]>=1.163.0' 'google-genai>=1.0.0'

pip install -r scripts/requirements.txt   # dependencias del skill de alertas

Dos detalles del flywheel: prohíbe crear un virtualenv porque arranca vacío y oculta paquetes que el entorno ya provee; y exige entrecomillar los especificadores de versión, porque sin comillas bash lee >=1.154.0 como una redirección y escribe un archivo vacío en silencio.

Buenas prácticas de instalación

Cuántos skills instalar

El comando del README permite elegir: “From the npx install command, you can select the specific skills from this repo to install.” El descubrimiento de Agent Skills, descrito en el curso de Agent Skills, carga en contexto el name y la description de cada skill instalado y solo abre el cuerpo del SKILL.md al activarlo. Con 103 descripciones de unos 429 caracteres de media, instalar el repositorio completo significa sostener del orden de 44.000 caracteres de metadatos en cada turno.

El problema real no es el volumen: es la colisión. Del catálogo, 28 directorios empiezan por gke- y 13 por agent-platform-, con descripciones parecidas por construcción. Por eso Google las escribió con la fórmula de tres tiempos del capítulo 4: qué hace, Use when… y Don't use for X (use otra-skill instead). Esa tercera frase aparece en 77 de las 103 descripciones —y en 24 de ellas cierra literalmente con instead)— y existe para resolver empates.

Criterio práctico:

Instala por sección del README, no por catálogo completo. Si tu trabajo es GKE, las 23 skills de Infrastructure más las 13 de Management tools tienen sentido; las 12 de Advertising no. Las secciones están mapeadas en el capítulo 3.
Las skills de Getting started y gcloud son transversales.
Los orquestadores —gke-productionize, google-cloud-solution-architecture— asumen instalados los especializados a los que delegan.
Revisa lo instalado cuando cambie el proyecto. Un catálogo bajo desarrollo activo no es una instalación que se hace una vez.

Cómo combinarlos con tus propios skills

Los skills de Google son de producto: saben de Cloud Run, de BigQuery, de Google Ads, y nada de tu convención de nombres, tu pipeline de CI o tu política de aprobación. Ahí va lo tuyo: un despliegue-interno/SKILL.md con tus entornos y aprobadores, un convenciones-terraform/SKILL.md con tu layout de módulos. Tres reglas para que no se pisen:

Escribe la frase de exclusión. En la description de tu skill, redirige explícitamente al de Google: Don't use for raw gcloud syntax (use gcloud instead). Es la misma fórmula que usa Google, y funciona en ambas direcciones.
No dupliques el conocimiento de producto. Si tu skill repite cómo se despliega un servicio en Cloud Run, tendrás dos fuentes que divergen. Deja que cloud-run-basics explique el producto y que el tuyo explique tu política.
Respeta los tiers de confirmación. Nueve skills del catálogo llevan una sección Safety & Confirmation Tiers (CRITICAL) —ocho como ## y agent-platform-alert-configuration como ###. Si tu skill envuelve a uno de ellos y se salta la confirmación, has anulado el control sin quererlo.

El formato exacto del SKILL.md está en el curso de Agent Skills; el empaquetado para distribuirlo, en el curso de Agent Plugins Spec.

Cómo fijar versiones

Los plugins sí están fijados. .claude-plugin/marketplace.json declara cada plugin con un ref explícito, y .gitmodules ancla los mismos 16 submódulos bajo plugins/cloud/data-agent-kit/:

{ "name": "spanner",
  "source": { "source": "github",
              "repo": "gemini-cli-extensions/spanner",
              "ref": "0.3.1" },
  "description": "Connect and interact with Spanner data using natural language." }

Los refs conviven en dos estilos según el repositorio de origen: 0.3.1 para spanner, 1.2.0 para google-cloud-storage, v0.4.0 para bigtable y v0.6.0 para db-context-engineering. El propio marketplace lleva metadata.version: "0.0.1". El detalle está en el capítulo 11.

Los skills individuales no. El comando npx skills add google/skills no expone un selector de versión, y metadata.version aparece solo en 13 de los 103 SKILL.md. No hay un contrato de versionado por skill que puedas invocar. Lo que sí puedes hacer es apoyarte en el permiso explícito del CONTRIBUTING.md —“You are encouraged to fork this repository and remix these skills”— y vendorizar el catálogo por tu cuenta:

git clone https://github.com/google/skills.git vendor/google-skills
cd vendor/google-skills && git checkout <SHA>   # fija el catálogo a un commit
cp -r skills/cloud/cloud-run-basics ../../.claude/skills/   # copia lo que usas

Actualizar pasa a ser un git diff contra el upstream revisado por ti, no un cambio silencioso en la próxima instalación. Con un repositorio under active development, esa diferencia importa.

Contribuir al catálogo

Lo que el repositorio no acepta

CONTRIBUTING.md es inequívoco desde su primer párrafo bajo Our Contribution Policy: “At this time, we are not accepting external pull requests or code contributions.” La justificación es doble: garantizar la exactitud técnica, la seguridad y el alineamiento arquitectónico de la guía, y someter todo skill a “a rigorous internal verification and approval process by Google teams”. Los equipos internos de Google se rigen por la documentación del Agent Skills Program y por la especificación SKILL.md. Traducido: no envíes un pull request, no se va a revisar.

Lo que sí acepta

El mismo archivo enumera tres vías bajo How You Can Help.

Reportar issues. Textualmente: “If you find a bug, an outdated SDK pattern, or a security anti-pattern in a skill, please open an issue.” El tracker es https://github.com/google/skills/issues. Un buen reporte lleva la ruta exacta skills/<area>/<nombre>/SKILL.md y la sección, la cita textual de lo que está mal, el comando o fragmento de SDK que falla con su error real, y la versión correcta según la documentación vigente.

Hay una imprecisión que abunda a esta escala: las referencias colgantes. Cuatro descripciones redirigen a skills que no existen en el repositorio:

Skill que la contiene	Nombre al que redirige
`skills/ads/ima-sdk-basics`	`ima-sdk-dai-basics`
`skills/cloud/agent-platform-deploy`	`vertex-deploy`
`skills/ads/google-ads-api-account-diagnostics`	`gma-android-integrate`
`skills/cloud/cloud-monitoring-chart-generation`	`cloud-monitoring-promql-query`

Las cuatro aparecen dentro de la frase Don't use for… de la descripción, y ninguno de esos nombres es un directorio del repositorio. Es exactamente el tipo de hallazgo que el tracker de issues espera.

Pedir skills nuevas. “If there is a Google product or a common cross-product architectural pattern you would like to see covered, please let us know via the issue tracker.” Lo interesante es la segunda mitad: no solo productos, también patrones arquitectónicos entre productos, la categoría de los 9 skills de Multi-product solution skills. Una propuesta útil responde a lo que responde cualquier SKILL.md: qué hace en una frase con verbo en presente, cuándo activarla con Use when…, cuándo no activarla y a qué skill redirigir, por qué no lo cubre ninguno de los 103 actuales, y si necesita references/, scripts/ o assets/.

Bifurcar y remezclar. “You are encouraged to fork this repository and remix these skills for your own specialized workflows.” La licencia lo permite sin ambigüedad: Apache 2.0, con el texto completo en LICENSE.

flowchart LR
    A[Hallazgo en el catalogo] --> B{Que tipo}
    B -->|Comando roto| C[Issue con ruta cita y error]
    B -->|Falta cobertura| D[Feature request]
    B -->|Comportamiento propio| E[Fork y remix bajo Apache 2.0]
    C --> F[Revision interna de Google]
    D --> F
    E --> G[Tu arbol de skills versionado por ti]

Fuera del catálogo también hay skills de Google

El README cierra con una sección Additional Google skills que enlaza seis repositorios independientes. Si no encuentras cobertura entre los 103, mira aquí antes de abrir un issue:

Nombre en el README	URL
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`

Es la razón por la que flutter-basics o genkit-basics no existen en google/skills. La excepción es firebase-basics, que sí vive en este catálogo con 19 archivos en references/, incluidas guías de setup por harness.

Cierre de la trilogía

Estos tres cursos cubren el mismo objeto desde tres alturas distintas.

flowchart LR
    A[Agent Skills] -->|el formato SKILL.md| B[Agent Plugins Spec]
    B -->|el empaquetado distribuible| C[Google Skills]
    C -->|103 skills publicados| D[Practica a escala real]

Agent Skills de 0 a Hero: el formato. Qué es un SKILL.md, cómo se escribe la description que decide la activación, cómo funciona la carga progresiva de references/.
Agent Plugins Spec de 0 a Hero: el empaquetado. Cómo skills, comandos y servidores MCP se vuelven un plugin distribuible con su marketplace.
Google Skills de 0 a Hero: la práctica. Qué pasa cuando una empresa publica 103 skills de una vez y empaqueta 16 plugins con sus versiones fijadas.

Leer este catálogo es la forma más rápida de aprender a escribir los tuyos, y por eso el curso se apoyó en abrir los archivos reales, no en describirlos de memoria.

Resumen

Los tres flujos encadenan skills reales: fundamentos con google-cloud-recipe-onboarding, google-cloud-recipe-auth, google-cloud-recipe-foundation-builder y gcloud; despliegue y observabilidad con cloud-run-basics, cloud-logging-configuration-basics, cloud-monitoring-metric-selection, cloud-monitoring-chart-generation, google-cloud-slo-alert-configuration y cloud-logging-query-generation; capa de IA con google-cloud-solution-build-deploy-agents, google-agents-cli-onboarding, agent-platform-deploy, agent-platform-eval-flywheel y agent-platform-alert-configuration.
gcloud es transversal y exige validar la sintaxis con gcloud help <comando-hoja> antes de proponer o ejecutar nada.
Instalar el catálogo completo carga 103 descripciones, unos 44.000 caracteres de metadatos por turno: instala por sección del README y mantén juntos los orquestadores con los skills a los que delegan.
Tus skills propios cubren política y convenciones, no conocimiento de producto, y declaran la frase Don't use for… que redirige a los de Google.
Los plugins están fijados por ref en .claude-plugin/marketplace.json y en .gitmodules. Los skills individuales no: solo 13 de 103 declaran metadata.version. Para fijarlos, vendoriza el repositorio a un commit.
CONTRIBUTING.md no acepta pull requests externos. Acepta issues por bugs, patrones de SDK obsoletos y antipatrones de seguridad, peticiones de skills nuevas, y fork con remix bajo Apache 2.0.
Cuatro descripciones redirigen a skills inexistentes: ima-sdk-dai-basics, vertex-deploy, gma-android-integrate y cloud-monitoring-promql-query, ejemplos concretos de lo que el tracker de issues espera recibir. Seis repositorios externos completan la cobertura: Flutter, Dart, Cloud Storage avanzado, ADK, Firestore y Genkit.