AI Native Notes
Volver a Gemini CLI
Gemini CLIAvanzado5 min de lectura

Sub-agentes y Orquestación de Skills

Cómo delegar trabajo en sub-agentes de Gemini CLI y activar skills especializadas para procesos repetibles y rigurosos.

sub-agentsskillsorchestrationparallel-executionworkflow

Referencias oficiales: Sub-agents · Skills · CLI Commands · Extensions overview

Ruta de aprendizaje

  1. Primeros pasos con Gemini CLI — instalación, autenticación y memoria
  2. La ventaja de 1M tokens — trabajar con codebases completos — análisis de repos sin derroche
  3. Gemini Extensions & MCP — crear flujos personalizados — empaquetar comandos, MCP y skills
  4. Trusted Folders, Sandboxing y Restore — confianza, aislamiento y rollback
  5. Headless Automation con Gemini CLI — scripts, CI y salida estructurada
  6. Sub-agentes y Orquestación de Skills — delegación y flujos especialistas ← Estás aquí
  7. Gemini Loop Seguro del Primer Día
  8. Playbook Gemini para Entregas de Escala Semanal
  9. Controles de Cambios de Alto Riesgo en Gemini
  10. Manual Operativo de Gemini — Ritmo Escalable de Entrega por CLI
  11. Gemini Playbook de Recuperación de Incidentes
  12. Gemini Bucle de Hardening Post-Incidente
  13. Gemini Simulacros de Resiliencia Caótica
  14. Gemini Métricas de Resiliencia y SLO

Documentación oficial usada en este artículo

  • Modelo de sub-agentes integrados y personalizados — Sub-agents
  • Capas de descubrimiento y activación de skills — Skills
  • Cómo una extension distribuye flujos especialistas — Extensions overview

Gemini mejora cuando no hace todo en el hilo principal

La tentación natural es hacer investigación, implementación, revisión y limpieza dentro de una sola conversación. Para tareas pequeñas funciona. Para trabajo grande, degrada rápido.

La clave es separar dos conceptos:

  • sub-agent: un trabajador al que delegas
  • skill: un cambio de comportamiento para el agente actual

Entender esa diferencia vuelve mucho más claro el diseño del workflow.

Los sub-agentes absorben el trabajo ruidoso

Un sub-agent es útil cuando el trabajo:

  • tiene alcance amplio
  • es repetitivo
  • amenaza con llenar el contexto principal

Los built-in sub-agents muestran bien la intención:

  • codebase_investigator para arquitectura amplia y root-cause analysis
  • agentes generalistas para tareas repetitivas o voluminosas
  • ayudantes centrados en CLI para dudas de uso
  • agentes orientados a navegador cuando hace falta interacción web

La idea es simple: “haz fuera la parte ruidosa y devuélveme un resumen limpio”.

Las skills no añaden mano de obra: cambian la mentalidad

Una skill no crea otro agente. Lo que hace es imponer un procedimiento especializado al agente actual.

Por eso son tan útiles para:

  • code review
  • security review
  • checklists de migración
  • preparación de releases
  • procesos internos de compliance

Si el sub-agent es un contratista, la skill es un modo profesional nuevo para el mismo operador.

Cuándo usar cada cosa

Situación Sub-agent Skill
Trabajo grande y ruidoso Sí A veces
Necesitas un procedimiento más estricto A veces Sí
Quieres conservar el contexto principal Sí No
Quieres que el agente siga una checklist especializada No Sí

En workflows avanzados se combinan:

  1. delegas discovery a un sub-agent
  2. activas una skill para implementación o revisión

Recetas prácticas de orquestación

1. Investigar un repo grande

  • empieza en Plan Mode
  • pide a codebase_investigator que mapee el sistema
  • resume riesgos
  • vuelve al modo normal solo cuando el borde del cambio esté claro

2. Limpieza repetitiva en muchos archivos

  • manda la parte repetitiva a un sub-agent generalista
  • deja que la sesión principal se concentre en revisar diffs y decidir tradeoffs

3. Revisión especializada

  • mantén el trabajo en el hilo principal
  • activa una skill como code-review o una skill propia del equipo
  • pide hallazgos en un formato estable

La regla útil es: búsqueda ruidosa fuera, juicio delicado cerca.

Las capas de descubrimiento de skills son un multiplicador real

La documentación explica que las skills pueden venir de varios niveles: usuario, workspace, extensiones e integradas. Eso permite decidir dónde vivirán las especialidades del equipo.

Una distribución razonable sería:

  • nivel usuario para hábitos personales
  • nivel workspace para convenciones del repo
  • nivel extension para distribución compartible
  • built-in para procedimientos generales

Ese modelo ayuda a pasar de prompts improvisados a un sistema operativo documentado para el equipo.

Convierte un prompt en skill solo cuando el checklist ya es estable

No todo prompt inteligente merece convertirse en skill. Hazlo solo si el flujo:

  • se repite mucho
  • es fácil de olvidar o ejecutar mal
  • tiene riesgo cuando se hace de forma inconsistente
  • puede verificarse después

Buenos candidatos:

  • auditoría de paridad entre idiomas
  • checklist de release
  • revisión de contratos API
  • QA de localización
  • revisión de preparación de publicación

Una mala skill es vaga. Una buena skill tiene definición de done repetible.

Cómo lo aplicaría en AI Native Notes

  1. codebase_investigator mapea routing, i18n y carga de contenido cuando aparece una duda arquitectónica
  2. una skill locale-review verifica paridad entre ko, en y es
  3. una skill content-release repasa metadata, enlaces y resumen de cambios antes de desplegar

Así el hilo principal se queda con estrategia y criterio, mientras la validación aburrida se mueve a rutas especialistas reutilizables.

El fallo más común: orquestar por espectáculo

Sub-agents y skills son potentes, así que es fácil abusar.

Señales de alerta:

  • lanzar sub-agents para tareas triviales
  • llamar skill a un prompt largo sin verificación real
  • delegar algo que el hilo principal necesita inmediatamente
  • crear cinco activos donde una línea en GEMINI.md bastaba

La orquestación buena quita ruido. No añade teatro.

Siguientes lecturas recomendadas

Guías Conectadas