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

Skills de soluciones multi-producto: arquitecturas completas

6 de agosto de 2026 Por: Artiko

agent-skillsplugins-de-agentesia-agentesgoogle-cloudarquitecturagkealloydbrag

Skills de soluciones multi-producto: arquitecturas completas

En el capítulo anterior vimos los skills de fundamentos: autenticación, onboarding y construcción de la base organizativa. Son skills de una sola pieza. Esta categoría es lo contrario: nueve skills que no resuelven un producto, sino una arquitectura entera, coordinando GKE, AlloyDB, Cloud Run, Cloud Storage, Cloud Armor, Spark gestionado y modelos abiertos dentro de un mismo diseño.

El README los agrupa bajo el epígrafe Multi-product solution skills, y cada uno lleva en su frontmatter el mismo marcador:

metadata:
  category: MultiProductSolutions

Todos viven en skills/cloud/ y todos empiezan por el prefijo google-cloud-solution-. Esa es la forma más rápida de listarlos:

ls skills/cloud/ | grep '^google-cloud-solution-'

Devuelve nueve directorios, ni uno más; los tienes todos en la tabla de la sección siguiente. Como siempre en este curso, el repositorio está marcado como under active development en su propio README: esa lista es una foto del catálogo, no un contrato.

El mapa: etiqueta del README contra ruta real

El README no usa el nombre del directorio como texto del enlace, sino un título en prosa. Conviene tener la traducción a mano, porque para invocar un skill lo nombras por su name, no por su etiqueta:

Etiqueta en el README	Ruta real en el repo
Google Cloud solution-architecture workflow	`skills/cloud/google-cloud-solution-architecture/`
Agentic analytics across cloud providers and data types	`skills/cloud/google-cloud-solution-agentic-analytics-spark-knowledge-catalog/`
Borderless open data lakehouse agentic AI system	`skills/cloud/google-cloud-solution-agentic-ai-borderless-data-lakehouse/`
Build and deploy AI agents on Google Cloud	`skills/cloud/google-cloud-solution-build-deploy-agents/`
Data science workflow with AI agents solution	`skills/cloud/google-cloud-solution-agentic-ai-data-science-workflow/`
Live bidirectional multimodal streaming agentic AI solution	`skills/cloud/google-cloud-solution-agentic-ai-bidirectional-streaming/`
Migrate AI Workloads to GKE Inference	`skills/cloud/google-cloud-solution-guided-gke-ai-migration/`
RAG for enterprise search using GKE and AlloyDB	`skills/cloud/google-cloud-solution-rag-enterprise-search-gke-sqldb/`
Secure n-tier serverless web application with strict private application tiers	`skills/cloud/google-cloud-solution-n-tier-serverless-web-app/`

Fíjate en el caso más traicionero: el skill de analítica agéntica se llama google-cloud-solution-agentic-analytics-spark-knowledge-catalog, con Spark y Knowledge Catalog en el nombre, pero en el README aparece como Agentic analytics across cloud providers and data types. Buscando por la etiqueta no lo encuentras en el árbol de directorios.

El patrón compartido: cuatro fases y un informe

Antes de repasarlos uno a uno conviene ver lo que tienen en común, porque es mucho. Los nueve implementan la misma máquina de estados, con variaciones menores de nombre:

flowchart LR
  P1[Fase 1<br/>Requirements discovery] --> P2[Fase 2<br/>Solution design]
  P2 --> P3[Fase 3<br/>Implementation plan]
  P3 --> P4[Fase 4<br/>Solution validation]
  P1 -.aprobacion explicita del usuario.-> P2
  P2 -.aprobacion explicita del usuario.-> P3
  P3 -.aprobacion explicita del usuario.-> P4

Cuatro reglas transversales, tomadas del texto real de los SKILL.md:

1. Separación estricta de fases. google-cloud-solution-architecture explica incluso el porqué:

Strict phase separation: During Phase 1 (Requirements discovery) […] don’t recommend, propose, or outline any architectural designs, technical decompositions, cloud services, or component mappings. Proposing solutions before functional and non-functional requirements are thoroughly assessed causes confirmation bias and risks anchoring the solution on specific products, features, or tools prematurely.

2. Aprobación iterativa en cada entregable. Descomposición técnica, selección de productos, diagrama, descripción, recomendaciones de diseño y guía de despliegue se presentan por separado y se iteran hasta que el usuario aprueba. El skill de RAG ordena la parada en seco: You MUST stop execution immediately, call no more tools (such as file editors, searches, or code tools), and wait for the user to respond.

3. Nada de ejecución autónoma. Ejecutar scripts sin permiso explícito e inequívoco puede aprovisionar recursos no deseados con costes inesperados, mutar infraestructura viva o abrir riesgos de seguridad; siempre se ofrece la opción de que ejecutes tú los comandos.

4. Grounding obligatorio. Varios exigen anclar lo generado en el servidor MCP https://developerknowledge.googleapis.com/mcp, con sus herramientas developerknowledge:search_documents, developerknowledge:get_documents y developerknowledge:answer_query, más los references/ del skill y citas a la documentación oficial.

Y una constante de formato: todos piden el diagrama de arquitectura en Mermaid, citando https://github.com/mermaid-js/mermaid. Ninguno acepta ASCII art ni una imagen. El diagrama es texto que el agente escribe, revisa contigo y empaqueta en el informe final, casi siempre llamado solution-architecture-guide.md y basado en assets/output-template.md. Esa plantilla existe en siete de los nueve. Las dos excepciones: google-cloud-solution-build-deploy-agents, que trae tres plantillas propias en assets/ y produce tres documentos en vez de uno; y google-cloud-solution-guided-gke-ai-migration, que no tiene ninguna plantilla de documento porque su salida no es un informe sino cinco plantillas YAML de Kubernetes. Si aún no tienes claro cómo se escribe un SKILL.md con este nivel de estructura, el curso hermano de Agent Skills explica el formato, y la anatomía de un skill de Google diseccionó uno de estos mismos casos.

El paraguas: google-cloud-solution-architecture

Ruta: skills/cloud/google-cloud-solution-architecture/

Es el genérico. Su description incluye cuándo no usarlo: Don’t use this skill when other specialized skills (e.g., product-specific or google-cloud-recipe-*) directly address the user’s workload or use case.

Qué arquitectura propone: ninguna en concreto. No trae opiniones sobre productos; trae el proceso. Sus referencias son catálogos de documentación:

skills/cloud/google-cloud-solution-architecture/
├── SKILL.md
├── assets/
│   └── output-template.md
└── references/
    ├── architecture-guides.md
    ├── best-practices-guides.md
    └── decision-making-guides.md

Esos tres ficheros son infraestructura compartida del catálogo: el skill de analítica agéntica referencia decision-making-guides.md y best-practices-guides.md por URL absoluta a GitHub en lugar de duplicarlos.

En su Task 2.4 delega las recomendaciones de los seis pilares en otros skills, si están instalados: google-cloud-waf-security, google-cloud-waf-reliability, google-cloud-waf-cost-optimization, google-cloud-waf-operational-excellence, google-cloud-waf-performance-optimization y google-cloud-waf-sustainability; si no están disponibles, deriva la guía de references/best-practices-guides.md. Su Fase 3 se parte en dos: validación pre-despliegue con terraform plan o gcloud ... --dry-run más análisis estático de rutas, firewalls e IAM; y validación en runtime, solo si decides desplegar, con comandos curl, ping o gcloud.

Cuándo lo invocarías: cuando tu carga es multi-producto y compleja pero no encaja en ninguno de los ocho patrones concretos. Es el fallback deliberado.

Las ocho soluciones concretas

Analítica agéntica sobre datos distribuidos

Ruta: skills/cloud/google-cloud-solution-agentic-analytics-spark-knowledge-catalog/

Arquitectura que propone: una canalización de analítica agéntica gobernada y segura sobre datos repartidos entre Google Cloud, otras nubes y on-premises. Los datos de fuera no se copian, se federan: su description nombra Databricks, Snowflake, Salesforce, SAP y Oracle, accedidos vía Apache Iceberg, métodos zero-copy ETL o remote query push-down.

La descomposición técnica no es libre; el skill obliga a organizarla en cuatro capas fijas: user-interaction layer (el IDE agéntico, con VS Code o Antigravity IDE nombrados en las preguntas de descubrimiento), grounding and trusted data (modelo de fundación, servidores MCP y almacén analítico), metadata curation (escaneo de metadatos, con Knowledge Catalog y su fichero references/knowledge-catalog-documentation.md) y data processing and analytics (flujos analíticos, Spark y almacenes externos). Además exige que la descomposición aborde seguridad basada en roles y credenciales.

Cuándo lo invocarías: cuando tienes inventario o histórico repartido entre S3, Azure Blob, Cloud Storage y bases como AlloyDB, y quieres que un científico de datos pregunte en lenguaje natural desde su IDE sin montar un ETL que duplique todo. El skill trae anticipada la contradicción típica de Fase 1: pedir zero-copy y a la vez copiar los datos a un repositorio central.

Lakehouse de datos abiertos sin fronteras

Ruta: skills/cloud/google-cloud-solution-agentic-ai-borderless-data-lakehouse/

Arquitectura que propone: un lakehouse abierto, gobernado y seguro que conecta silos de datos con agentes de IA y ejecuta consultas federadas entre Google Cloud y fuentes externas. Es el único del grupo que impone reglas explícitas sobre el contenido del diagrama: debe mostrar una distinción clara entre los productos del subsistema de ingesta y los del subsistema de servicio, y debe mostrar Managed Service for Apache Spark como componente compartido que hace de puente entre ambos.

Otra particularidad: es el único con references/product_renaming.md, y su SKILL.md abre con una sección Product Renaming & Terminology. El skill de ciencia de datos trae la misma idea en forma de tabla dentro de su propio SKILL.md:

Legacy Name	Updated Name
Vertex AI	Gemini Enterprise Agent Platform
Vertex AI Agent Engine	Gemini Enterprise Agent Runtime

Con una advertencia útil: las APIs, los recursos de Terraform y los roles de IAM pueden conservar sus identificadores antiguos.

Cuándo lo invocarías: cuando el problema es de joins entre nubes y federación de metadatos, no de una sola bodega de datos. Su description te saca de ahí si el caso es simple: Don’t use for simple single-cloud data warehouses or non-AI workloads.

Construir y desplegar agentes en Google Cloud

Ruta: skills/cloud/google-cloud-solution-build-deploy-agents/

Arquitectura que propone: un sistema agéntico completo, desde el patrón de diseño hasta el despliegue. Su Fase 1 incluye un paso que los demás no tienen, Recommend agent design pattern, con dos salidas: single-agent system para tareas simples, punto de partida efectivo para refinar la lógica central y las herramientas; y multi-agent system para problemas complejos con varios agentes especializados.

Es el skill con más artefactos del grupo: tres plantillas en assets/ (solution-template.md, implementation-template.md, validation-template.md) y tres ficheros en references/ (design-principles.md, product-mappings.md, related-guidance.md). Deja tres documentos en tu workspace: solution-architecture.md, implementation-instructions.md y validation-plan.md.

Sus instrucciones de implementación son inusualmente prescriptivas. Cuatro mandatos literales de la Fase 3: dar el código ADK exacto de un nodo de agente con estado que tome un prompt, llame a un modelo y devuelva una petición de ejecución de herramienta; registrar herramientas como lectores de base de datos usando Model Context Protocol; configurar Cloud Run para escalar a cero cuando el agente está inactivo; y usar variables de entorno cifradas para credenciales privadas, porque de lo contrario acaban en texto plano en los logs del contenedor. También integra la Agents CLI en las tres fases: agents-cli scaffold create o agents-cli scaffold enhance, agents-cli deploy (con --dry-run o -n), y agents-cli run junto a agents-cli eval run para probar y evaluar antes de desplegar.

Cuándo lo invocarías: cuando diseñas o implementas un sistema agéntico sobre Google Cloud. Su description marca las fronteras: para arquitectura general usa google-cloud-solution-architecture; para tareas estrechas contra un solo producto sin contexto de agentes, ninguno de los dos.

Flujo de ciencia de datos con agentes

Ruta: skills/cloud/google-cloud-solution-agentic-ai-data-science-workflow/

Arquitectura que propone: una arquitectura agéntica de ciencia de datos multi-producto. Lo distintivo es que preselecciona el patrón de coordinación en vez de dejarlo abierto: su Fase 2 fija como patrón primario recomendado el Coordinator pattern, y enumera tres alternativas con su criterio de uso: single-agent para cargas acotadas a una sola fuente y uso directo de herramientas; sequential or parallel para canalizaciones deterministas con pasos predefinidos y no adaptativos, o recolección concurrente; y review and critique para tareas complejas o de alto riesgo que requieren bucles dedicados de crítica.

Su Fase 1 obliga a detenerse: You must halt and wait for the user to answer these questions before proceeding to the Identify components step. Las preguntas son cuatro: fuentes y tipos de datos, usuarios objetivo y modelo de acceso de red, tipos de consulta esperados, y restricciones de rendimiento, seguridad o gobernanza.

Cuándo lo invocarías: al arquitecturar analítica basada en agentes o cargas de ML multi-producto. Su description excluye consultas simples, canalizaciones no agénticas, revisiones generales de nube y escribir el código del agente.

Streaming multimodal bidireccional en vivo

Ruta: skills/cloud/google-cloud-solution-agentic-ai-bidirectional-streaming/

Arquitectura que propone: un sistema multi-agente que procesa flujos continuos de datos multimodales para dar guía técnica en tiempo real y monitorización de seguridad. Sus preguntas de descubrimiento revelan el caso de uso: modalidades de entrada de audio, vídeo o texto; latencia objetivo de la respuesta narrada; detección de peligros o inspección visual sobre el flujo de vídeo; bases de conocimiento o repositorios de esquemas que los agentes deben consultar; y limitaciones del cliente y de la red.

El mapeo de references/product-mapping.md recomienda como primaria una combinación concreta: Regional External Application Load Balancer con Cloud Armor para ingreso HTTP, HTTPS y WebSocket, y Direct VPC egress para el acceso privado desde Cloud Run; Cloud Run como frontend y como runtime del agente; Agent Development Kit como framework; el protocolo Agent2Agent entre agentes; y Gemini Enterprise Agent Platform como runtime del modelo. De cada uno lista alternativas con pros y contras. Su Fase 3 enlaza recursos muy específicos, entre ellos el codelab Way Back Home Level 4 y su código en https://github.com/gca-americas/way-back-home/tree/main/level_4.

Cuándo lo invocarías: cuando hay streaming en vivo y bidireccional de verdad. Su description cierra la puerta: Don’t use for simple text-based chat applications or workloads without real-time streaming requirements.

Migración de cargas de IA a GKE Inference

Ruta: skills/cloud/google-cloud-solution-guided-gke-ai-migration/

El más operativo del grupo y el que más se parece a un runbook. No produce un informe: produce manifiestos.

skills/cloud/google-cloud-solution-guided-gke-ai-migration/
├── SKILL.md
└── assets/
    ├── ccc-profile.yaml.tmpl
    ├── gke-inference-gateway.yaml.tmpl
    ├── model-staging-job.yaml.tmpl
    ├── storage-config.yaml.tmpl
    └── vllm-deployment.yaml.tmpl

Arquitectura que propone: un golden path de inferencia autoalojada en GKE con opiniones firmes:

Nodos: Custom Compute Classes para maximizar la obtenibilidad de aceleradores, con drivers de GPU gestionados por GKE.
Motor de inferencia: vLLM con la imagen vllm/vllm-openai, y una anulación obligatoria del entrypoint —command: ["python", "-m", "vllm.entrypoints.openai.api_server"]— para saltarse scripts de arranque problemáticos como gcs_download_launcher.sh de las imágenes de Vertex AI.
Versionado: nunca :latest. El tag estable se resuelve en tiempo de diseño y se registra en migration-state.md; prohíbe reutilizar un tag recordado de otra migración o de un ejemplo de la documentación.
Exposición: GKE Gateway API, por defecto el balanceador interno regional gatewayClassName: gke-l7-rilb, con un HTTPRoute que manda /v1 al servicio ClusterIP {workload_name}-vllm-svc en el puerto 8000. Para balanceo consciente del LLM, ofrece GKE Inference Gateway con InferencePool como backend. Los modelos multi-nodo usan LeaderWorkerSet junto a vLLM.
Almacenamiento y observabilidad: pesos en Cloud Storage montados con Cloud Storage FUSE, o Managed Lustre para latencia ultrabaja a escala de petabytes, con el staging vía un Job del clúster guardado como model-staging-job.yaml; y Google Cloud Managed Service for Prometheus con métricas DCGM.

Tiene tres guardarraíles notables. El primero es la trampa del autoescalado de LLM: prohíbe asumir que quieres HPA, obliga a preguntarlo, y si lo aceptas advierte de que CPU, memoria y utilización de VRAM son métricas poco fiables porque vLLM preasigna la VRAM para la caché KV y siempre parece saturada; recomienda escalar por profundidad de cola, por ejemplo vllm:num_requests_waiting. El segundo es el manejo de secretos para modelos con acceso restringido: nunca escribir el valor literal del token, referenciarlo con env.valueFrom.secretKeyRef apuntando a hf-secret, no escribir jamás un manifiesto Secret en disco y pedirte que lo crees tú por CLI antes de aplicar nada:

kubectl create secret generic hf-secret --namespace={namespace} --from-literal=hf_api_token=<YOUR_HF_TOKEN>

El tercero es el desvío hacia MCP: si pides automatizar la migración con el servidor MCP de Gemini Cloud Assist, el skill se detiene y responde con cuatro puntos obligatorios, porque su ámbito es la migración manual guiada usando gcloud y kubectl. Cada respuesta arquitectónica abre con un indicador de progreso literal:

**Migration Progress:** [● Discovery] ➔ [○ Solution Design] ➔ [○ Implementation] ➔ [○ Validation]

Cuándo lo invocarías: cuando ya tienes una carga de inferencia en Cloud Run, la Gemini API, Gemini Enterprise Agent Platform o una VM propia y quieres moverla a GKE autoalojado. Si no hay nada que migrar, el propio skill te manda a skills/cloud/gke-inference/, que veremos en el capítulo de infraestructura.

RAG empresarial con GKE y AlloyDB

Ruta: skills/cloud/google-cloud-solution-rag-enterprise-search-gke-sqldb/

Arquitectura que propone: búsqueda conversacional privada, segura y de baja latencia sobre contenido corporativo, con restricciones que aparecen ya en la description: la base vectorial tiene que ser una base SQL, el modelo abierto, el motor de inferencia open source, y todos los componentes hospedados en contenedores de Kubernetes. Su descomposición técnica está fijada en nueve componentes: ingesta, procesamiento y chunking, generación de vectores de embedding, almacenamiento e indexado de esos vectores, tratamiento de los datos no vectoriales, consulta y recuperación, aumento del prompt, generación de la respuesta y comprobaciones de sanidad de la respuesta.

Los productos salen de references/product-selection-recommendations.md: Cloud Storage con el driver CSI de Cloud Storage FUSE para montar buckets en los pods; GKE Autopilot por defecto; Ray, con Ray Data y Ray Core, para orquestar el chunking multi-worker; AlloyDB for PostgreSQL como almacén e índice de vectores, con el argumento explícito de que permite convivir metadatos relacionales con los embeddings sin crear silos; GemmaEmbedding para generar vectores y Gemma para generar respuestas, servidos con vLLM sobre GKE. Las alternativas también están nombradas: Cloud SQL for PostgreSQL con pgvector y Vector Search de Gemini Enterprise Agent Platform.

El diagrama, tal como lo describe su SKILL.md

La Task 2.2 de este skill no solo pide un diagrama Mermaid: incluye un ejemplo textual de los dos flujos que debe mostrar. Este es ese ejemplo llevado a Mermaid, sin añadir nada que el SKILL.md no diga:

flowchart TD
  subgraph EMB[Embedding pipeline - batch o streaming]
    DS[Data source] --> GCS[Cloud Storage]
    GCS --> FUSE[Cloud Storage FUSE]
    FUSE --> RAY[GKE Ray Worker - chunking]
    RAY --> GEM[Embedding generation con GemmaEmbedding]
    GEM --> ADB[(AlloyDB - vector store)]
  end

  subgraph SRV[Serving pipeline - tiempo real]
    UC[User client] --> FE[GKE Frontend - orquestacion LangChain]
    FE --> Q[Database query - busqueda semantica o hibrida]
    Q --> ADB
    ADB --> RET[Retrieve matching data]
    RET --> AUG[Augment prompt]
    AUG --> VLLM[Gemma vLLM endpoint API]
    VLLM --> OUT[Output con filtrado de Responsible AI]
    OUT --> UC
  end

Cada nodo y cada flecha sale del texto literal del skill; su referencia primaria de arquitectura es https://docs.cloud.google.com/architecture/rag-capable-gen-ai-app-using-gke.md.txt. La Fase 3 de validación tampoco es genérica: terraform plan, rutas y endpoints, verificación de que los índices vectoriales están creados y poblados en AlloyDB, prueba de la canalización de embeddings de extremo a extremo, latencia de las consultas vectoriales e híbridas, relevancia de los fragmentos recuperados, y comprobación de accesos restringidos, firewall e IAM.

Cuándo lo invocarías: cuando quieres RAG bajo tu control, con base SQL vectorizada y modelos abiertos sobre Kubernetes. Su description te expulsa si el caso es otro: DON’T use this skill for fully-managed RAG, or SaaS search services, or when a non-SQL vector database is required.

Aplicación web serverless n-tier

Ruta: skills/cloud/google-cloud-solution-n-tier-serverless-web-app/

Arquitectura que propone: aislamiento físico y de red estricto entre capas, con Cloud Run en las capas de aplicación y Cloud SQL for PostgreSQL como capa de datos. Según el SKILL.md: el Tier 1 es el servicio público de UI o gateway en Cloud Run, que expone el punto de entrada vía Cloud Load Balancing y enruta hacia dentro por Direct VPC Egress; los Tier 2..N son servicios privados en Cloud Run, 100% isolated from the internet; y la capa de datos es Cloud SQL privado más Memorystore for Redis para caché, alcanzables solo desde las capas autorizadas.

Su Fase 1 es la más peculiar del catálogo: en vez de entrevistarte, adopta un golden path del 80 % y se permite solo dos preguntas de desambiguación: balanceador global con Cloud CDN o regional sin CDN por residencia de datos, y si quieres capa de caché Memorystore for Redis. Ese golden path fija región us-central1, Cloud SQL for PostgreSQL POSTGRES_18 Enterprise Edition vía Private Service Connect, Cloud Armor con la regla sqli-v33-stable, Direct VPC Egress con ALL_TRAFFIC, zona privada de Cloud DNS run.app. y sidecar de Cloud SQL Auth Proxy con autenticación IAM. Y trae algo que ningún otro del grupo tiene: assets/main.tf, un Terraform completo que el SKILL.md trata como fuente de verdad, más references/non-negotiable-architectural-rules.md con las reglas que el agente no puede negociar contigo, entre ellas forzar INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER en el Tier 1 para que nadie se salte el balanceador golpeando la URL *.run.app.

Cuándo lo invocarías: cuando necesitas una web n-capas serverless con capas internas realmente privadas. Su description excluye diseños basados en VM o GKE.

Cómo elegir entre los nueve

El catálogo trae las reglas de enrutamiento escritas en las description y en los avisos de scope check. Resumidas:

flowchart TD
  START{Que tipo de carga} --> WEB[Web n-capas serverless]
  START --> AGENTS[Sistema agentico]
  START --> DATA[Datos y analitica]
  START --> INFER[Inferencia de modelos]
  START --> OTRO[Nada de lo anterior]

  WEB --> S_NTIER[google-cloud-solution-n-tier-serverless-web-app]

  AGENTS --> Q_STREAM{Streaming bidireccional en vivo}
  Q_STREAM -->|si| S_STREAM[google-cloud-solution-agentic-ai-bidirectional-streaming]
  Q_STREAM -->|no| S_AGENTS[google-cloud-solution-build-deploy-agents]

  DATA --> Q_FED{Datos fuera de Google Cloud}
  Q_FED -->|si, federados| S_LAKE[google-cloud-solution-agentic-ai-borderless-data-lakehouse]
  Q_FED -->|si, con catalogo y Spark| S_ANALYTICS[google-cloud-solution-agentic-analytics-spark-knowledge-catalog]
  Q_FED -->|no| S_DS[google-cloud-solution-agentic-ai-data-science-workflow]

  INFER --> Q_MIG{Ya existe una carga desplegada}
  Q_MIG -->|si| S_MIG[google-cloud-solution-guided-gke-ai-migration]
  Q_MIG -->|no, y es busqueda RAG| S_RAG[google-cloud-solution-rag-enterprise-search-gke-sqldb]
  Q_MIG -->|no, despliegue nuevo| S_GKEINF[gke-inference]

  OTRO --> S_ARCH[google-cloud-solution-architecture]

La regla que se repite: si un skill especializado cubre tu caso, úsalo; el genérico es el último recurso. Y a la inversa, cada especializado sabe cuándo devolverte al genérico o a otro skill del catálogo.

Instalarlos

Los comandos son los del README, sin variaciones:

# skills.sh: te deja seleccionar que skills concretos instalar
npx skills add google/skills

# Claude Code: primero el marketplace, luego el plugin
claude plugin marketplace add google/skills
claude plugin install <plugin>@google-plugins

# Codex
codex plugin marketplace add google/skills

# Antigravity CLI: apuntando a la ruta del plugin en el repositorio
agy plugin install https://github.com/google/skills/<plugin-path>

El detalle de cada método está en el capítulo de instalación, y el empaquetado en plugins distribuibles, en el curso hermano de Agent Plugins Spec y en el capítulo de plugins y marketplace. Estos nueve tampoco son la única fuente de skills de Google: el README enlaza además Flutter Skills, Dart Skills, Advanced Google Cloud Storage Skills, Agent Development Kit Skills, Firestore Skills y Genkit Skills.

Lo que se puede copiar

Aunque no trabajes con Google Cloud, esta categoría demuestra que un skill puede ser un proceso de consultoría, no una función. Cuatro decisiones trasladables a cualquier dominio: fases con puerta de aprobación; detección de contradicciones antes de diseñar, bloqueando el resto hasta resolverlas; salida con formato fijo, que hace comparables las ejecuciones; y el golden path del skill n-tier, que cuando el espacio de diseño es conocido prefiere una opinión por defecto y dos preguntas a un cuestionario de veinte, para prevenir la multi-turn interview fatigue.

Resumen

La categoría MultiProductSolutions tiene exactamente 9 skills, todos en skills/cloud/ con el prefijo google-cloud-solution-.
google-cloud-solution-architecture es el genérico y el fallback; sus tres ficheros de references/ son infraestructura compartida que otros skills referencian por URL.
Las otras ocho son patrones concretos: n-tier serverless, RAG con GKE y AlloyDB, migración a GKE Inference, construcción de agentes, ciencia de datos agéntica, streaming multimodal bidireccional, lakehouse sin fronteras y analítica agéntica con Spark y Knowledge Catalog.
Todos comparten el mismo esqueleto: cuatro fases, separación estricta entre descubrimiento y diseño, aprobación explícita en cada entregable, prohibición de ejecutar código sin permiso, grounding contra documentación oficial y diagrama de arquitectura en Mermaid.
Cada description incluye su condición de exclusión: esa frase de “don’t use for…” es el mecanismo de enrutamiento del catálogo. Y como el repositorio está bajo desarrollo activo, verifica con ls skills/cloud/ antes de dar por buena una ruta.

Siguiente: Skills de AI/ML y Agent Platform