GUION VIDEO: Claude Code Agent Teams: 7 Agentes que Crean Skills para Otros Agentes

Título: Claude Code Agent Teams: 7 Agentes que Crean Skills para Otros Agentes Duración estimada: 45-48 minutos Formato: Concepto + Demo en vivo (skills múltiples con edición) Filosofía: “Sin Humo” — proceso real, incluyendo los problemas reales Serie: Trilogía Claude Code Avanzado — Video 3 de 3

ESTRATEGIA DE RETENCIÓN

Indicadores en el Guion

Indicador	Significado	Propósito
OPEN LOOP	Promesa que entregas DESPUÉS	Generar anticipación
PAYOFF	Entrega del valor prometido	Recompensar al viewer
PATTERN INTERRUPT	Cambio de ritmo, visual o energía	Romper monotonía
CURIOSITY GAP	Generar curiosidad sobre algo específico	Mantener atención
PROGRESS TRACKING	Mostrar avance en el video	Validar tiempo invertido

Mapa de Retención Minuto a Minuto

Minuto	Técnica	Objetivo
0:00	HOOK — construiste una fábrica, no una skill	Identificación inmediata
0:45	OPEN LOOP #1	”En el minuto 21 el Lead se va a detener y preguntarte algo antes de arrancar”
1:15	OPEN LOOP #2	”En el minuto 38 Claude va a elegir la skill correcta de cuatro disponibles — sin que le digas cuál”
2:00	CURIOSITY GAP #1	”¿Por qué un agente que solo elimina texto vale más que uno que escribe?“
2:30	CURIOSITY GAP #2	”¿Por qué el agente que coordina todo no necesita el modelo más caro?“
2:50	CURIOSITY GAP #3	”Descubrí algo testeando en código real que cambió completamente la arquitectura. En el minuto 9.”
5:00	PATTERN INTERRUPT	Diagrama — Teams vs Subagentes
8:00	PAYOFF conceptual	El CLAUDE.md con los 4 roles
9:00	PATTERN INTERRUPT	La asimetría del sistema — WOW conceptual
13:00	PATTERN INTERRUPT	Task list de dos fases en pantalla
15:00	PATTERN INTERRUPT	Tabla de model routing — el segundo contrato
17:00	PROGRESS TRACKING	”Ya tienes el setup. Ahora el demo.”
20:00	MEGA PAYOFF #1	Demo empieza — FASE 1: Lead + Investigador
21:00	PAYOFF OPEN LOOP #1	El Lead se detiene y pregunta
23:00	WOW VISUAL #1	Investigador buscando docs reales en registry.terraform.io
27:00	WOW VISUAL #2	FASE 2: Los 3 teammates aparecen simultáneamente
35:00	MEGA PAYOFF #2	Skill #1 publicada
35:30	PATTERN INTERRUPT	”Eso fue una. Vamos con tres más.”
37:00	WOW VISUAL #3	Portal va de 1 → 4 skills con cortes rápidos
38:00	MEGA PAYOFF #3	Nueva sesión — Claude elige la skill correcta
40:00	PATTERN INTERRUPT	Análisis post-demo
43:00	PAYOFF FINAL	Árbol de decisión + cierre trilogía

KEYWORDS A ATACAR

Primarias:

“claude code agent teams”
“agent skills claude”
“ai agents crear skills”

Secundarias:

“claude code tutorial”
“multi agent system”
“agent skills best practices”

En español:

“agentes ia colaborar”
“claude code agentes”
“fabrica de skills ia”

ESTRUCTURA GENERAL

[0:00-2:00]    HOOK + OPEN LOOPS + CURIOSITY GAPS
[2:00-5:00]    RECAPITULACIÓN DE LA TRILOGÍA
[5:00-8:00]    EL PROBLEMA: LA FÁBRICA DE SKILLS
[8:00-15:00]   AGENT TEAMS + EL CLAUDE.md (incluye asimetría del sistema)
[15:00-17:00]  EL SEGUNDO CONTRATO: MODEL ROUTING + EXIT CONDITIONS
[17:00-18:30]  POR QUÉ ES DESARROLLO, NO PRODUCCIÓN
[18:30-20:00]  SETUP DEL DEMO
[20:00-35:00]  DEMO SKILL #1 — PIPELINE COMPLETO EN VIVO
[35:00-37:30]  SKILLS #2, #3, #4 — CORTES RÁPIDOS (editados)
[37:30-38:30]  NUEVA SESIÓN — CLAUDE ELIGE LA SKILL CORRECTA (MEGA PAYOFF)
[38:30-41:00]  ANÁLISIS POST-DEMO
[41:00-43:00]  ÁRBOL DE DECISIÓN
[43:00-45:00]  CIERRE DE LA TRILOGÍA + CTA

GUION MINUTO A MINUTO

[0:00 — 2:00] HOOK + OPEN LOOPS

TOMA: Cámara directa, sin setup, fondo oscuro

GUION:

“Hoy no te voy a mostrar cómo crear una skill.”

[Pausa]

“Te voy a mostrar cómo construir una fábrica que crea skills por ti.”

[Pausa — mirar a cámara]

“La diferencia es enorme. Una skill es un resultado. Una fábrica es un sistema que produce resultados — cualquier resultado que le pidas. Le dices qué necesitas. El equipo investiga, escribe, debate, comprime y publica. Tú no tocas nada.”

“Al final de este video el portal va a tener cuatro skills de dominios completamente distintos. Infraestructura, redes, DevOps, herramientas de IA. Todas creadas por el mismo equipo. En el mismo pipeline.”

[Pausa — beat de 2 segundos]

“Este es el tercer video de una trilogía. Hoy cerramos el sistema completo.”

OPEN LOOP #1 (segundo 45):

“En el minuto 21 vas a ver al Lead detenerse antes de arrancar y preguntarte algo. Una sola pregunta. Cuando la veas vas a entender por qué esa pregunta vale más que todo el demo.”

[Mostrar brevemente: terminal — 1 pane, el Lead escribiendo]

OPEN LOOP #2 (segundo 75):

“Y en el minuto 38 vamos a abrir una sesión completamente nueva de Claude — sin darle contexto, sin decirle qué skills existen — y Claude va a elegir la correcta de cuatro disponibles. Sin que nadie le diga cuál usar.”

CURIOSITY GAP #1:

“Antes de llegar al demo hay una pregunta: en este equipo hay un rol que no escribe nada. Solo elimina. Y ese rol es el que más reduce el costo de todo lo que el equipo produce. En el minuto 10 explico por qué.”

CURIOSITY GAP #2:

“Segunda pregunta: si el sistema corre con siete agentes, ¿todos necesitan el modelo más caro? En el minuto 15 te muestro el tiering que usamos — incluyendo una decisión de modelo que el Lead toma en tiempo real según la complejidad de cada request.”

CURIOSITY GAP #3:

“Y hay algo que descubrí mientras preparaba este video — probando en código real — que cambió completamente cómo diseñé la arquitectura. El sistema tiene una asimetría que nadie documenta. Minuto 9.”

[Pausa — transición]

TIP DE GRABACIÓN:

“Hoy no te voy a mostrar cómo crear una skill” — pausa larga antes de la frase siguiente
“Una fábrica que crea skills por ti” — decirlo despacio, que quede claro el contraste
Los OPEN LOOPS deben sonar como promesas reales, no hype
No mencionar tecnología específica en los primeros 90 segundos

[2:00 — 5:00] RECAPITULACIÓN DE LA TRILOGÍA

TOMA: Cámara 50% + clips de videos anteriores 50%

“Este es el tercer video de una trilogía. Cada uno responde una pregunta diferente.”

MOSTRAR EN PANTALLA:

TRILOGÍA CLAUDE CODE AVANZADO

Video 1 — Agent Skills
"¿Cómo defines lo que un agente puede hacer?"
→ Las Reglas

Video 2 — ADK + A2A
"¿Cómo construyes sistemas que corren solos?"
→ La Fábrica de Ejecución

Video 3 — Agent Teams (hoy)
"¿Cómo construyes el equipo que crea las reglas?"
→ La Fábrica de Skills

[Video 1 — Agent Skills]:

“En el primer video vimos Agent Skills. La idea central: cómo encapsular capacidades reutilizables para un agente. En Claude Code eso se implementa con un SKILL.md — instrucciones que definen cuándo usar una capacidad y cómo ejecutarla. Esos archivos son lo que el equipo de hoy va a crear — a escala, para cualquier herramienta que necesites.”

[Video 2 — ADK + A2A]:

“En el segundo video construimos la fábrica de ejecución. Siete agentes con Google ADK coordinados por el protocolo A2A. Lo corrimos en local, pero el patrón es el mismo que usarías para desplegarlo como servicio autónomo.”

[Frase puente]:

“Hoy construimos la fábrica de skills. El taller que crea las herramientas que después esos agentes — y cualquier Claude — van a usar.”

TIP DE GRABACIÓN:

Máximo 3 minutos — no es el foco
Clips de los momentos más visuales de los videos anteriores
“La fábrica de skills” — decirlo despacio, es el concepto central del video

[5:00 — 8:00] EL PROBLEMA: LA FÁBRICA DE SKILLS

TOMA: Cámara directa 70% + pantalla 30%

PATTERN INTERRUPT — tono más conversacional:

“Quiero ir profundo en el problema antes del demo, porque si no lo entiendes, el demo va a parecer un truco.”

“Cada vez que Claude necesita hacer algo específico — crear una instancia en GCP, configurar un tunnel, publicar un paquete — hay dos opciones.”

MOSTRAR EN PANTALLA:

OPCIÓN A — Sin skill:
  Tú explicas el proceso cada vez.
  Claude lo ejecuta.
  La próxima vez, explicas de nuevo.
  El conocimiento no se acumula.

OPCIÓN B — Con fábrica de skills:
  El equipo crea la skill una vez.
  Claude la carga automáticamente cuando la necesita.
  La próxima vez, el conocimiento ya está.
  El sistema se vuelve más capaz con cada skill creada.

“La fábrica convierte conocimiento tuyo en instrucciones permanentes para Claude. Y puede hacer eso con cualquier herramienta.”

MOSTRAR en pantalla — lo que la fábrica puede crear:

"skill para crear una VM en Google Cloud con Terraform"
"skill para exponer servicios locales con Cloudflare Tunnels"
"skill para configurar CI/CD con GitHub Actions"
"skill para crear un servidor MCP en Python"
"skill para configurar OAuth2"
"skill para hacer deploy en Vercel"
"skill para configurar backups en S3"
...

“No hay un tipo de skill. No hay un dominio específico. Cualquier procedimiento que puedas describir, el equipo puede convertirlo en instrucciones para Claude.”

[Mirar a cámara]

“El trabajo difícil no es pedirle skills al equipo. Es diseñar bien el contrato que define cómo trabajan. Qué preguntan antes de arrancar, qué asumen, cuándo se detienen. Eso es lo que vamos a ver.”

TIP DE GRABACIÓN:

La lista de skills en pantalla — leerlas todas en voz alta, no solo mostrarlas
“Cualquier procedimiento que puedas describir” — pausa antes, es el insight central
Tono reflexivo, no técnico

[8:00 — 15:00] AGENT TEAMS + EL CLAUDE.md DE 4 ROLES

TOMA: Pantalla 60% + cámara 40%

PATTERN INTERRUPT — cambio a pantalla:

[8:00 — 10:00] Agent Teams vs Subagentes

“Antes del demo, la diferencia fundamental entre los dos modos que Claude Code tiene.”

[Diagrama: Subagentes]

“Subagentes: cada uno hace una tarea acotada y reporta hacia arriba. No saben que existen los otros. No debaten. Perfectos cuando solo el resultado importa — buscar documentación, validar un archivo, publicar a una API.”

[Diagrama: Agent Teams]

“Agent Teams: los teammates se hablan directamente. Comparten una task list. El Arquitecto le puede decir al Revisor ‘revisa esto’ — el Revisor responde con problemas concretos. Sin que yo intervenga.”

MOSTRAR TABLA:

                    SUBAGENTES          AGENT TEAMS
                    ──────────          ───────────
¿Quién habla?       Solo al principal   Entre sí + al principal
Coordinación        El principal        Task list compartida
Costo en tokens     Bajo                Alto — cada teammate = sesión
Ideal para          Ejecución acotada   Decisiones que requieren debate

“La pregunta para decidir: ¿los trabajadores necesitan hablarse para hacer bien el trabajo? No — subagentes. Sí — Agent Teams.”

[9:00 — 10:00] La asimetría que nadie documenta — PAYOFF CURIOSITY GAP #3

PATTERN INTERRUPT — mirar a cámara, tono de descubrimiento:

“Y acá está lo que descubrí preparando este video. Lo encontré haciendo un test en vivo.”

[Pausa]

“Los teammates en un Agent Team no tienen acceso al Task tool. No pueden lanzar subagentes. Punto. Solo el Lead puede hacerlo.”

MOSTRAR en pantalla:

HERRAMIENTAS DE UN TEAMMATE:
Bash, Glob, Grep, Read, Edit, Write,
WebFetch, WebSearch, SendMessage...

Task tool: ❌ no disponible

“Cuando lo descubrí, tuve dos opciones: ver esto como una limitación, o entender por qué el sistema está diseñado así.”

[Pausa — mirar a cámara]

“La respuesta es elegante. El sistema es asimétrico por diseño. El Lead orquesta hacia afuera — coordina subagentes, ejecuta scripts, publica a APIs. Los teammates trabajan hacia adentro — debaten entre sí, construyen el artefacto. Son dos capas con responsabilidades distintas.”

“Y esa asimetría me forzó a una arquitectura mejor: el Lead investiga primero, solo. Cuando el equipo entra, ya tiene el contexto listo. El equipo debate con información — no en el vacío.”

MOSTRAR diagrama:

FASE 1: Lead actúa solo
Lead ──→ Investigador (subagente) ──→ research

FASE 2: El equipo entra con contexto
Lead ──→ Arquitecto ┐
        Revisor     ├── debaten entre sí
        Optimizador ┘
         ↓
Lead ──→ Validador (subagente) → resultado
Lead ──→ Publisher (subagente) → portal

“Sin esa restricción técnica, probablemente habría diseñado algo más complejo — y menos claro.”

TIP DE GRABACIÓN:

“Lo encontré haciendo un test en vivo” — honestidad, no drama
La tabla de herramientas — dejar un segundo antes de mostrar la ❌
El diagrama de dos fases — revelar FASE 1 primero, luego FASE 2
Tono: descubrimiento genuino

[10:00 — 14:00] El CLAUDE.md — los 4 roles

PAYOFF del CURIOSITY GAP (minuto 2: “el rol que solo elimina”):

“Y acá viene la respuesta a la pregunta del inicio. El rol que solo elimina.”

[Pantalla: CLAUDE.md del proyecto]

“Defino 4 roles. Y el cuarto es el que cambia todo respecto a lo que haría un equipo normal.”

MOSTRAR los 4 roles:

### Lead
Coordina. Antes de crear tareas, detecta ambigüedades
bloqueantes y pregunta. No diseña ni opina sobre el contenido.

### Arquitecto
Escribe el SKILL.md como instrucciones para Claude — no
para humanos. Claude ya sabe qué es un provider de Terraform,
qué es un registro DNS, qué es OAuth.
No explica lo que Claude ya sabe.

### Revisor
Verifica que Claude ejecutaría correctamente estas
instrucciones. No busca errores para humanos — busca
ambigüedades que Claude podría malinterpretar.
¿El description dice cuándo usar esta skill?
¿Hay valores hardcodeados que deberían ser placeholders?

### Optimizador
Entra después del consenso. Su único trabajo: eliminar
todo lo que Claude no necesita.
— ¿Estás explicando algo que Claude ya sabe? Eliminar.
— ¿Supera 500 líneas? Comprimir.
— ¿Hay repetición? Eliminar.

[Mirar a cámara — énfasis]

“El Optimizador no agrega nada. Solo substrae. Y eso reduce el tamaño final de la skill — lo que directamente reduce los tokens que consume cada vez que Claude la usa. Es el FinOps del equipo.”

“Y fíjate en el Arquitecto: escribe para Claude, no para humanos. Claude no necesita que le expliques qué es un bloque de Terraform. Necesita saber qué recursos crear, qué decisiones tomar y cómo manejar los errores. Eso es todo.”

[14:00 — 15:00] La task list

“El pipeline tiene dependencias claras.”

MOSTRAR:

[TASK 1] Investigar docs                → Investigador    [disponible]
[TASK 2] Escribir SKILL.md             → Arquitecto      [dep.→TASK 1]
[TASK 3] Revisar SKILL.md              → Revisor         [dep.→TASK 2]
[TASK 4] Comprimir SKILL.md            → Optimizador     [dep.→TASK 3]
[TASK 5] Validar                       → subagente       [dep.→TASK 4]
[TASK 6] Publicar                      → subagente       [dep.→TASK 5]

“Cada rol no puede empezar hasta que el anterior terminó. Y el Publisher no corre si la validación falló.”

PROGRESS TRACKING:

“Ya tienes el contexto completo. Ahora viene lo que importa — el demo.”

[15:00 — 17:00] EL SEGUNDO CONTRATO: MODEL ROUTING + EXIT CONDITIONS

TOMA: Pantalla 70% + cámara 30%

PATTERN INTERRUPT — cambio de tono, más directo:

“Hay otro contrato que nadie menciona cuando diseña un Agent Team. Y es el que más impacto tiene en el costo.”

[Pausa]

“Si corres siete agentes, todos en el modelo más caro, el costo escala linealmente. Pero eso asume algo que no es verdad: que todos los roles necesitan el mismo nivel de razonamiento.”

MOSTRAR en pantalla — la pregunta de decisión:

¿El rol necesita razonar sobre contexto no estructurado?
  → Sonnet

¿El rol ejecuta instrucciones con criterios explícitos?
  → Haiku

“Una sola pregunta. Y cuando la aplicas a cada rol, el resultado es muy diferente a lo que esperarías.”

MOSTRAR tabla — revelar fila por fila:

Rol              Modelo         Por qué
──────────────   ────────────   ──────────────────────────────────────────
Lead             Haiku          Coordina y delega — sigue instrucciones
                                explícitas. No razona sobre contexto abierto.
Arquitecto       Sonnet         Sintetiza docs no estructuradas.
                                Decide qué necesita Claude.
Revisor          Sonnet         Interpreta ambigüedades que requieren
                                juicio, no aplicación mecánica de reglas.
Optimizador      Haiku          Aplica criterios explícitos definidos
                                en el CLAUDE.md. Sin creatividad.
Investigador     Haiku / Sonnet Dinámico — el Lead decide según
                                la complejidad del request. (*)
Validador        Haiku          Ejecuta ./validate.sh. Devuelve resultado.
Publisher        Haiku          Ejecuta ./publish.sh. Verifica respuesta.

”(*) El Investigador es el único rol con modelo variable. Para herramientas con docs estructuradas como Terraform Registry — Haiku es suficiente. Para APIs nuevas, documentación no estructurada, o múltiples servicios que se coordinan — el Lead asigna Sonnet. El Lead evalúa eso antes de lanzarlo, con criterios explícitos en el CLAUDE.md.”

[Pausa — mirar a cámara]

“Opus no aparece. En ningún lugar de este pipeline hay una tarea que lo justifique.”

TRANSITION:

“Pero hay un segundo problema de costo que es menos obvio.”

[Pausa]

“Sin condiciones de salida explícitas, los agentes siguen iterando después de que su trabajo terminó. El Revisor puede mandar objeciones para siempre. El Optimizador puede seguir comprimiendo más allá de lo útil.”

MOSTRAR en pantalla:

CONDICIONES DE SALIDA POR ROL

Revisor      → Máximo 2 rondas de objeciones al Arquitecto.
               Si en la segunda no aparecen problemas nuevos,
               aprueba con razón explícita. No puede seguir objetando.

Arquitecto   → Termina cuando SKILL.md existe y Revisor aprobó.
               No itera más. No "mejora" sin que el Revisor lo pida.

Optimizador  → Termina cuando: (1) body < 500 líneas
               Y (2) eliminó al menos 1 sección o bloque.
               Ni antes ni después.

“El primer contrato define qué hace cada rol. El segundo define cuándo para.”

“Modelo correcto por rol, más condiciones de salida explícitas: eso es lo que separa un Agent Team que funciona de uno que quema presupuesto en rendimientos decrecientes.”

[17:00 — 18:30] POR QUÉ ES DESARROLLO, NO PRODUCCIÓN

TOMA: Cámara directa

“Una cosa importante antes del demo.”

MOSTRAR:

POR QUÉ AGENT TEAMS ES DESARROLLO, NO PRODUCCIÓN:

1. Si los teammates toman una dirección equivocada,
   los demás pueden seguirlos. Necesitas un humano
   para corregir.

2. Agent Teams vive dentro de tu sesión interactiva.
   No es un servicio que despliegas. Cuando cierras
   el terminal, termina.

3. El sistema asume que hay alguien mirando.
   No es un runtime autónomo como ADK.

4. Para tareas riesgosas existe plan approval:
   el teammate muestra su plan y espera aprobación
   explícita antes de ejecutar.

“El caso de uso correcto es este: tú en tu máquina, el equipo trabajando a tu lado, creando algo que después va a producción. El proceso es interactivo. El resultado no.”

[18:30 — 22:00] SETUP DEL DEMO

TOMA: Pantalla + cámara pequeña arriba

La flag

“Para habilitar Agent Teams necesitas una sola configuración en tu settings.json de Claude Code.”

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

“Sin esta línea el feature no existe. Con ella, Claude Code habilita el Team tool y los teammates pueden coordinarse.”

El repositorio — los 4 archivos que hacen funcionar el sistema

[Mostrar árbol del repo en pantalla]

├── CLAUDE.md
├── validate.sh
├── publish.sh
└── skills/

“El sistema tiene 4 piezas. Vamos una por una.”

CLAUDE.md — el contrato del equipo

[Abrir CLAUDE.md en pantalla]

“Este es el archivo más importante. Define los 7 roles — quién hace qué, con qué modelo, y cuándo termina su trabajo. Sin esto el equipo no existe.”

“Cuando Claude Code arranca en este directorio, lee este archivo automáticamente. El Lead sabe que debe preguntar antes de arrancar. El Arquitecto sabe que escribe instrucciones para Claude, no para humanos. El Revisor sabe que tiene máximo 2 rondas. Todo viene de acá.”

[Mostrar sección de roles en el CLAUDE.md]

“Esto es lo que reemplaza al prompt largo. No necesito explicarle los roles cada vez — están definidos una sola vez, acá.”

validate.sh — lo que ejecuta el Validador

[Abrir validate.sh en pantalla]

“Antes de publicar, el Validador corre este script. Verifica que el SKILL.md esté bien formado: que tenga frontmatter, que el name esté en kebab-case, que la description no supere 200 caracteres.”

[Mostrar en terminal:]

./validate.sh skills/terraform-gcp-compute

“Si pasa: 0 errores. Si falla: el Publisher no corre. Sin validación, sin publicación.”

publish.sh — lo que ejecuta el Publisher

[Abrir publish.sh en pantalla]

“Este script hace dos cosas en un solo comando. Primero sube la skill al portal Hermit vía API.”

“Segundo — y esto es importante para el MEGA PAYOFF que vienen a ver después — instala la skill localmente en ~/.claude/skills/. Eso hace que Claude la cargue automáticamente en cualquier sesión nueva, sin que nadie se la configure.”

El portal Hermit

[Browser: localhost:8080 — portal vacío]

“Las skills publicadas viven acá. Hermit es un portal open source, self-hosted, Docker Compose. Ahora está vacío. Al final del demo tiene cuatro skills de dominios completamente distintos.”

tmux

“Uso tmux para que veas los teammates trabajando simultáneamente. Cada pane es una sesión de Claude distinta — un agente distinto.”

PROGRESS TRACKING:

“Eso es todo el setup. Un archivo de configuración, tres scripts, y el portal. Ahora sí — le voy a mandar una sola línea al equipo. Con una ambigüedad adentro — a propósito.”

tmux new-session -s demo

Correr Claude dentro del pane

claude

[20:00 — 35:00] DEMO SKILL #1 — PIPELINE COMPLETO EN VIVO

TOMA: Pantalla completa — tmux con 1 pane al inicio (solo el Lead)

MEGA PAYOFF #1:

[20:00 — 21:00] El prompt

“El prompt es ambiguo a propósito.”

[Escribir en Claude Code — 1 pane, solo el Lead:]

Necesito una skill para crear infraestructura en Google Cloud.

Activa el Agent Team con estos roles:
- Arquitecto: diseña la skill como instrucciones para Claude —
  no para humanos. Usa el research que te proveo.
  Si falta información para algún paso, dilo.
- Revisor: verifica que Claude ejecutaría bien estas instrucciones.
  Busca ambigüedades, hardcode, y problemas en el description.
- Optimizador: comprime. Elimina todo lo que Claude ya sabe.

No intervengo en el debate técnico.

Cuando lleguen a consenso, usa subagentes para
validar y publicar en Hermit.

“No dije qué herramienta. ‘Infraestructura en Google Cloud’ puede ser Terraform, puede ser gcloud CLI, puede ser Pulumi. El Lead tiene que resolverlo antes de arrancar.”

[20:00 — 27:00] FASE 1: El Lead actúa solo

TOMA: 1 pane — solo el Lead. Los otros panes vacíos.

“Fase 1. El Lead trabaja solo. El equipo todavía no existe.”

[21:00 — 22:00] PAYOFF OPEN LOOP #1 — El Lead se detiene

“Y acá viene el momento que prometí.”

[El Lead detecta la ambigüedad y escribe:]

Antes de arrancar, necesito confirmar la herramienta.
"Infraestructura en Google Cloud" puede implementarse
de varias formas.

¿Qué herramienta usamos?
1. Terraform (hashicorp/google provider)
2. gcloud CLI directamente
3. Pulumi

[Pausa — mirar a cámara]

“Ahí está. El Lead se detuvo. No asumió. No eligió por el usuario.”

“Esa pregunta parece simple. Pero si el Lead hubiera asumido Terraform y el usuario usa gcloud CLI — toda la skill habría tenido los comandos equivocados.”

“Eso es el contrato funcionando.”

[Respondo: Terraform]

[22:00 — 25:00] El Investigador busca — solo, con el Lead

[Mostrar el Investigador como subagente — buscando documentación]

“Ahora el Lead no spawnea el equipo todavía. Primero lanza el Investigador — un subagente — para buscar documentación real.”

“El Investigador no busca ‘cómo crea un humano una instancia’. Busca ‘qué necesita saber Claude para ejecutar esto’. La pregunta es diferente. El resultado también.”

[Mostrar el Investigador accediendo a registry.terraform.io — URLs reales en pantalla]

“Fuente primaria. Documentación oficial. No alucinaciones.”

“Y fíjate en el modelo: esta herramienta es Terraform, tiene docs estructuradas en el registry, el request es acotado — un recurso. El Lead asignó Haiku al Investigador. Para este caso, es suficiente.”

[25:00 — 27:00] El Lead prepara el brief — la transición

[Investigador devuelve resultados al Lead]

“El Investigador termina. Devuelve el research al Lead.”

[Pausa — construir anticipación]

“Ahora el Lead tiene todo: la herramienta confirmada, los recursos reales, los edge cases documentados. Solo ahora spawnea al equipo.”

[Pausa]

“Mira.”

[27:00 — 35:00] FASE 2: El equipo entra con contexto

TOMA: PATTERN INTERRUPT — los 3 panes aparecen simultáneamente

[Zoom out — tmux con 3 panes nuevos activos al mismo tiempo]

“Los tres teammates aparecen al mismo tiempo. Con el research del Investigador ya en su contexto.”

[Beat — dejar que el viewer procese el visual]

“Esta es la diferencia entre un equipo que debate en el vacío y uno que debate con información.”

[27:00 — 30:00] El Arquitecto diseña — para Claude

[Mostrar el Arquitecto escribiendo el SKILL.md]

“El Arquitecto tiene los docs del registry.terraform.io y la herramienta confirmada. Mira cómo escribe.”

[Mostrar el HCL que produce — bloques reales de Terraform:]

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 7"
    }
  }
}

provider "google" {
  project = "<PROJECT_ID>"
  region  = "<REGION>"
  zone    = "<ZONE>"
}

resource "google_compute_instance" "<INSTANCE_NAME>" {
  name         = "<INSTANCE_NAME>"
  machine_type = "<MACHINE_TYPE>"
  zone         = "<ZONE>"
  allow_stopping_for_update = true
  deletion_protection       = false
  ...
}

“Fíjate en lo que no hay. No explica qué es un provider. No explica qué es HCL. No hay prerequisitos que Claude ya conoce.”

“Solo lo que Claude necesita: los bloques exactos, los placeholders donde van los valores del usuario, los campos que GCP requiere. Eso es todo.”

[30:00 — 33:00] El Revisor — encuentra problemas reales

[Mostrar el Revisor analizando el borrador]

“El Revisor toma el borrador. Su pregunta no es ‘¿funciona esto para un humano?’ — es ‘¿Claude ejecutaría esto correctamente?’”

[Mostrar el mensaje del Revisor al Arquitecto con los issues]

“Cuatro problemas reales. Entre ellos: deletion_protection no estaba en el template — si el usuario lo activa manualmente después, terraform destroy falla sin instrucción de cómo resolverlo.”

[El Arquitecto corrige. El Revisor aprueba en ronda 2.]

“Dos rondas. El contrato dice máximo dos. En la segunda no aparecieron problemas nuevos — el Revisor aprobó.”

[33:00 — 35:00] El Optimizador — de 179 a 146 líneas

PATTERN INTERRUPT:

“Arquitecto y Revisor llegaron a consenso. Entra el Optimizador.”

[Mostrar before/after — pantalla dividida]

Antes:

179 líneas

Después:

146 líneas

“33 líneas menos. Eran contexto que Claude no necesitaba. El SKILL.md final es 18% más pequeño — lo que se multiplica en tokens cada vez que Claude la carga.”

[34:30 — 35:00] Validación y publicación

“El Optimizador termina. El Lead lanza los subagentes.”

[Output del validate.sh]

✅ Validación pasada: 0 errores

[Publisher — ir al browser]

“Publicada. Skill número uno en el portal.”

[Pausa — mirar a cámara]

“Eso fue una. Vamos con tres más.”

[35:00 — 37:30] SKILLS #2, #3, #4 — CORTES RÁPIDOS

TOMA: Cortes editados — cada skill en 30-45 segundos

PATTERN INTERRUPT — ritmo más rápido, energía diferente:

“El mismo equipo. El mismo pipeline. Tres requests distintos.”

SKILL #2 — cloudflare-tunnels

[Corte: prompt al equipo]

Necesito una skill para exponer servicios locales
a internet con Cloudflare Tunnels.

[Corte rápido: Investigador buscando en developers.cloudflare.com] [Corte: Arquitecto escribiendo — el comando cloudflared tunnel create] [Corte: Revisor encontrando un edge case] [Corte: validate.sh verde] [Corte: portal — aparece cloudflare-tunnels]

“Redes. Sin IP pública, con HTTPS.”

SKILL #3 — github-actions-deploy

[Corte: prompt al equipo]

Necesito una skill para configurar deploy
automático con GitHub Actions.

[Corte: Investigador en docs.github.com] [Corte: Arquitecto generando el workflow YAML] [Corte: Optimizador eliminando bloques] [Corte: portal — aparece github-actions-deploy]

“DevOps. Deploy automático con cada push.”

SKILL #4 — mcp-server-setup

[Corte: prompt al equipo]

Necesito una skill para crear un servidor MCP
en Python que le dé herramientas nuevas a Claude.

[Corte: Investigador en la documentación oficial de MCP] [Corte: Arquitecto generando el código Python con FastMCP] [Corte: la skill incluye el paso de registro en settings.json] [Corte: portal — aparece mcp-server-setup]

“AI tooling. Claude aprendiendo a extenderse a sí mismo.”

[Mostrar el portal completo]

✓ terraform-gcp-compute    v1.0.0
✓ cloudflare-tunnels       v1.0.0
✓ github-actions-deploy    v1.0.0
✓ mcp-server-setup         v1.0.0

[Pausa — dejar que el viewer procese]

“Cuatro dominios distintos. Un equipo. El mismo pipeline para todos.”

[37:30 — 38:30] NUEVA SESIÓN — CLAUDE ELIGE LA SKILL CORRECTA

TOMA: Pantalla completa — nueva terminal, nueva sesión de Claude

MEGA PAYOFF #3 — PAYOFF OPEN LOOP #2:

“Prometí en el Open Loop que íbamos a abrir una sesión nueva — sin contexto, sin decirle qué skills existen. Ahora.”

[Abrir nueva terminal — nueva sesión de Claude Code]

[Primer prompt:]

Necesito exponer mi app de Node que corre en
localhost:3000 a internet con HTTPS. No tengo
IP pública.

[Claude carga cloudflare-tunnels automáticamente y ejecuta los pasos]

[Pausa — mirar a cámara]

“No le dije que existía cloudflare-tunnels. No le dije qué skill usar. Claude leyó el description de cada skill, identificó el trigger — ‘sin IP pública, HTTPS’ — y la cargó sola.”

[Segundo prompt — misma sesión:]

Quiero que Claude tenga acceso a mi base
de datos PostgreSQL para hacer consultas.

[Claude carga mcp-server-setup automáticamente]

[Pausa larga]

“Dos requests completamente distintos. Claude eligió la skill correcta en cada uno. Sin que nadie le dijera cuál.”

[Pausa]

“El equipo creó cuatro skills. Ahora Claude las usa. Y las va a seguir usando en cualquier sesión futura — de cualquier persona que las tenga instaladas.”

[Mirar a cámara]

“Eso es lo que significa construir una fábrica.”

[38:30 — 41:00] ANÁLISIS POST-DEMO

TOMA: Cámara directa + portal en pantalla

PATTERN INTERRUPT — reflexión:

“Quiero hacer el análisis que vale la pena hacer.”

[Portal con las 4 skills en pantalla]

MOSTRAR tabla en pantalla:

ANÁLISIS DEL EQUIPO — POR QUÉ CADA ROL IMPORTA

Rol            Aportó                              Sin él
────────────   ─────────────────────────────────   ─────────────────────────────────
Lead           Herramienta correcta + research      Skill para herramienta equivocada
Investigador   Comandos reales con fuente primaria  Comandos inventados o desactualizados
Arquitecto     Instrucciones para Claude            Skill para humanos, no para Claude
Revisor        Issues reales corregidos             Errores que Claude encontraría al ejecutar
Optimizador    -18% de tokens por skill             40% más tokens en cada uso futuro

[Mirar a cámara]

“Cada rol resolvió un problema diferente. Y ninguno de esos problemas habría aparecido si hubieras creado la skill solo en 10 minutos.”

[Pausa — nueva tabla]

“Y la dimensión que más importa a largo plazo:”

MOSTRAR:

EL SISTEMA ACUMULA

Cada skill creada → conocimiento permanente para Claude
Cada sesión futura → menos contexto que tienes que proveer
Cada skill que el equipo crea → la fábrica es más valiosa

Hoy: 4 skills
Mañana: le pides otra
La semana que viene: otra más

El equipo no se cansa. El conocimiento no desaparece.

“Otras personas van a usar estas skills. Tú construiste la fábrica.”

[Tabla de costo por modelo]

COSTO DEL PIPELINE — CON Y SIN MODEL ROUTING

                    Sin tiering          Con tiering
                    (todos Sonnet)       (modelo dinámico)
                    ─────────────        ────────────────────
Lead                Sonnet × ops         Haiku × ops  ✓
Arquitecto          Sonnet × ops         Sonnet × ops
Revisor             Sonnet × ops         Sonnet × ops
Optimizador         Sonnet × ops         Haiku × ops  ✓
Investigador        Sonnet × ops         Haiku o Sonnet ✓
Validador           Sonnet × ops         Haiku × ops  ✓
Publisher           Sonnet × ops         Haiku × ops  ✓

“El primer contrato — los roles — define qué se produce. El segundo contrato — modelos y condiciones de salida — define cuánto cuesta producirlo.”

[Tabla de la trilogía]

LA TRILOGÍA COMPLETA

Herramienta    ¿Dónde vive?     Objetivo                  Capa de control
────────────   ──────────────   ───────────────────────   ──────────────────────────────
Agent Skills   Repositorio      El contrato — las reglas  Capa 1 — instrucciones (SKILL.md)
ADK + A2A      Servidor (prod)  Ejecución autónoma         Capa 2 — restricción real (tools=[])
Agent Teams    Terminal (dev)   Crear las herramientas    Capa 1 + humano en el loop

“Cada herramienta tiene su lugar. No son intercambiables — son complementarias.”

[41:00 — 43:00] ÁRBOL DE DECISIÓN

TOMA: Pantalla con árbol de decisión

“Para cerrar, el mapa de decisión completo.”

MOSTRAR ÁRBOL:

¿Los agentes necesitan hablarse para hacer bien el trabajo?
│
├── NO → Subagentes
│         Ejecución acotada. Solo el resultado importa.
│         Más barato, más rápido.
│         Ejemplos: buscar docs, validar archivo, publicar a API.
│
└── SÍ → ¿El resultado va a correr solo en producción, 24/7?
          │
          ├── SÍ → ADK + A2A
          │         Restricciones reales de Capa 2 (tools=[]).
          │         Corre sin supervisión.
          │         Ejemplos: pipeline de facturación,
          │         soporte automatizado, IDP completo.
          │
          └── NO → Agent Teams
                    Diseño asistido — humano en el loop.
                    Supervisado, interactivo, en tu máquina.
                    Ejemplos: crear skills, diseñar arquitecturas,
                    revisar documentación antes de publicar.
                    ⚠️ No reemplaza tests ni CI —
                       acelera el diseño y la revisión.

“La pregunta más importante no es qué herramienta usar. Es: ¿qué tan bien definiste el contrato? Si el CLAUDE.md es ambiguo, el equipo va a tomar decisiones que tú no querías que tomara.”

[43:00 — 45:00] CIERRE DE LA TRILOGÍA + CTA

TOMA: Cámara directa

PAYOFF FINAL:

“Con esto cerramos los tres videos.”

[Pausa]

“Agent Skills es el formato — cómo se empaqueta una instrucción para Claude. ADK es la fábrica de ejecución — cómo se ejecuta en producción de forma autónoma. Agent Teams es la fábrica de skills — donde se crea el conocimiento que después todos usan.”

[Pausa — mirar a cámara]

“Y el trabajo más difícil en la fábrica no lo hacen los agentes. Lo haces tú cuando defines cuándo deben preguntarte y cuándo deben avanzar solos. Eso es el contrato. Y ese contrato es lo que hace que el sistema funcione o no.”

CTA:

“El repositorio completo está en el link de la descripción — el CLAUDE.md con los 4 roles, los scripts, las cuatro skills de ejemplo.”

“Si lo vas a probar, empieza con una skill de algo que conoces bien y observa qué pregunta el Lead y qué asume. Ahí vas a ver exactamente qué tan bien definiste el contrato.”

“Si el video te aportó algo, el like ayuda. Preguntas sobre la implementación, en los comentarios.”

“Hasta el próximo.”

NOTAS DE PRODUCCIÓN

Decisión de visualización — ANTES DE GRABAR

Opción A — tmux (recomendado):

brew install tmux
tmux new-session -s demo

Claude Code detecta tmux y distribuye los teammates automáticamente en panes separados.

Opción B — modo in-process: Un solo pane. Cambiar entre teammates con Shift+Down. Menos visual pero más simple de configurar.

Skills a pre-grabar antes de grabar el video

Para la sección de cortes rápidos [35:00-37:30], las skills #2, #3, #4 deben estar grabadas con anterioridad:

cloudflare-tunnels ✅ ya existe
github-actions-deploy — grabar en sesión separada
mcp-server-setup — grabar en sesión separada

El portal en el video real debe mostrar las 4 skills acumulándose. Opciones:

Pre-grabar cada creación y editar los cortes rápidos
Crear las 4 en una sesión de grabación antes del video principal

Tomas requeridas

Cold open: cámara directa, sin setup
Cámara: bloques 0:00, 2:00, 5:00, 15:00, 38:30, 41:00, 43:00
Screen recording: bloques 8:00 en adelante
tmux con panes activos para el WOW VISUAL #2
Before/after Optimizador: pantalla dividida (179 líneas vs 146 líneas)
Portal: vacío → skill #1 → skills #1 al #4 → nueva sesión con selección automática
Árbol de decisión con revelación progresiva
Clips de videos anteriores para la recapitulación

Archivos a preparar antes de grabar

CLAUDE.md actualizado (model routing dinámico del Investigador)
validate.sh y publish.sh funcionando contra Hermit local
Portal Hermit corriendo — probar 48h antes
.env con token configurado
Skills #2, #3, #4 pregrabadas
Segunda sesión de Claude preparada con las 4 skills instaladas (backup del MEGA PAYOFF)

Advertencias del demo en vivo

Agent Teams es lento — múltiples sesiones en paralelo. Red estable.
Si el Lead no pregunta la herramienta (asume en vez de preguntar): “Lead, ¿tienes toda la información para arrancar?”
El Optimizador puede ser el cuello de botella — si tarda mucho: “Optimizador, ¿cuántas líneas eliminaste?”
Tener resultado pregrabado como backup para el MEGA PAYOFF.
Puerto Hermit 8080 — verificar que no colisione con otros servicios.

SHORTS RECICLADOS

Batch A: Concepto (5 shorts)

Short 1: “Construiste una fábrica, no una skill” (WHY) — 45 seg

Timestamp: 0:00-1:30
El hook completo — fábrica vs skill única
Tags: agent teams, ai agents, claude code

Short 2: “El rol que solo elimina texto” (HOW) — 45 seg

Timestamp: 10:00-11:30
El Optimizador — FinOps del equipo
Tags: claude code, agent teams, token optimization

Short 3: “Por qué el Lead se detiene antes de arrancar” (WOW) — 60 seg

Timestamp: 21:00-22:00
El Lead detecta la ambigüedad, pregunta la herramienta
Tags: agent teams demo, ai agents, claude code experimental

Short 3B: “La asimetría que descubrí en Agent Teams” (WOW) — 60 seg

Timestamp: 9:00-10:00
El test en vivo + la tabla de herramientas + el diagrama de dos fases
Hook: “Los teammates en un Agent Team no pueden lanzar subagentes. Lo descubrí testeando en código real.”
Tags: agent teams, claude code, ai agents architecture

Short 4B: “Por qué el coordinador corre en el modelo más barato” (WHY) — 60 seg

Timestamp: 15:00-17:00
La tabla de tiering + model routing dinámico del Investigador
Hook: “¿El agente que coordina todo necesita el modelo más caro? No.”
Tags: agent teams cost, model routing ai, token optimization

Batch B: Demo (4 shorts)

Short 5: “El mismo equipo, cuatro skills distintas” (WOW) — 60 seg

Timestamp: 35:00-37:30 comprimido
Los 4 cortes rápidos — portal llenándose
Tags: agent teams demo, claude code, ai agents

Short 6: “De 179 a 146 líneas — el Optimizador en acción” (WOW) — 45 seg

Timestamp: 33:00-35:00
Before/after pantalla dividida
Tags: agent teams, token optimization, claude code

Short 7: “Claude elige la skill correcta sin que le digas cuál” (WOW) — 45 seg

Timestamp: 37:30-38:30
El MEGA PAYOFF — dos prompts, dos skills distintas, selección automática
Tags: agent skills, claude code, ai agents

Short 8: “Cómo saber si necesitas Agent Teams” (HOW) — 60 seg

Timestamp: 41:00-43:00
El árbol de decisión completo
Tags: agent teams vs subagentes, claude code tutorial

DESCRIPCIÓN SEO

Claude Code Agent Teams: 4 agentes que construyen una fábrica de skills
para Claude. El equipo investiga, escribe, debate, comprime y publica —
vos solo decís qué necesitás. Demo en vivo: el equipo crea cuatro skills
de dominios distintos (Terraform GCP, Cloudflare Tunnels, GitHub Actions,
MCP server) y Claude las usa automáticamente en una sesión nueva.
También: model routing dinámico por complejidad, condiciones de salida
explícitas, y por qué Opus no aparece en ningún lugar del pipeline.
Tercer video de la trilogía Claude Code Avanzado.

Tags:

claude code agent teams, agent skills claude, claude code tutorial,
ai agents crear skills, multi agent system, agent skills best practices,
claude code experimental, agentes ia, claude code agentes,
agent teams vs subagentes, token optimization ai, mcp server claude,
terraform gcp claude, fabrica skills ia

COMENTARIO FIJADO

🔗 Repositorio completo (CLAUDE.md, scripts, skills de ejemplo):
→ github.com/nneira/skills-portal-demo

🐳 Portal Hermit (self-hosted):
→ github.com/hermit-labs/hermit

📄 Agent Skills docs (oficiales):
→ code.claude.com/docs/en/skills

⏱️ Timestamps:
0:00 — Hook: la fábrica vs la skill
2:00 — Recapitulación de la trilogía
5:00 — El problema: qué es una fábrica de skills
8:00 — Agent Teams vs Subagentes
9:00 — La asimetría del sistema (teammates no pueden lanzar subagentes)
10:00 — El CLAUDE.md: 4 roles (Lead, Arquitecto, Revisor, Optimizador)
13:00 — La task list: arquitectura de dos fases
15:00 — El segundo contrato: model routing dinámico + condiciones de salida
17:00 — Por qué es desarrollo, no producción
18:30 — Setup (flag + tmux + Hermit + repo)
20:00 — DEMO: el prompt ambiguo
21:00 — FASE 1: El Lead pregunta la herramienta
22:00 — El Investigador busca en registry.terraform.io (solo, con el Lead)
27:00 — FASE 2: Los 3 teammates aparecen simultáneamente
28:00 — El Arquitecto escribe HCL para Claude, no para humanos
31:00 — El Revisor encuentra 4 issues reales
34:00 — El Optimizador: de 179 a 146 líneas
35:00 — Skills #2, #3, #4: cloudflare-tunnels, github-actions, mcp-server
37:30 — Nueva sesión: Claude elige la skill correcta de cuatro disponibles
38:30 — Análisis post-demo (tabla de contribuciones + costo por modelo)
41:00 — Árbol de decisión: Teams vs Subagentes vs ADK
43:00 — Cierre de la trilogía

🎬 Video anterior — ADK + A2A: [link]
🎬 Video anterior — Agent Skills: [link]

MINIATURA (3 opciones)

Opción 1: “La fábrica”

Fondo oscuro
Portal con 4 skills listadas en pantalla
Texto grande: “4 SKILLS”
Texto pequeño: “1 equipo. cualquier herramienta.”
Tu cara 20% — expresión de quien construyó algo

Opción 2: “Antes / Después”

Split horizontal: 179 líneas arriba (verbose), 146 líneas abajo (conciso)
Texto central: “179 → 146”
Tu cara en la esquina señalando la diferencia

Opción 3: “Los 4 panes”

Screenshot de tmux con los panes activos — los 4 agentes trabajando
Texto encima: “LA FÁBRICA”
Tu cara 20% observando

Versión: 2.0 | Fecha: 2026-03-03 | Estado: Borrador actualizado — 4 skills, factory framing