Templates y Componentes para Claude Code: El Futuro de los Flujos de Trabajo de Codificación de IA

Hola a todos. Mi nombre es Daniel Avila y hoy voy a hablar sobre plantillas y componentes para Cloud Code, el futuro del flujo de trabajo de codificación de IA. Antes de comenzar, voy a compartir mis cuentas de redes sociales para que puedan seguirme y ver todo el contenido que comparto. Algunos de ellos están en español, otros están en inglés, pero básicamente estoy compartiendo todo lo que he aprendido a lo largo de los años trabajando con diferentes modelos de lenguaje en el desarrollo de código.

Un poco sobre mí. He estado trabajando en tecnología por más de 15 años y he fundado dos startups. También he aprendido cómo implementar inteligencia artificial en el desarrollo de software. Y he dado muchas charlas en diferentes países sobre agentes de IA y cómo aplicarlos a lo largo de todo el ciclo de desarrollo de software. Esta vez, voy a hablarles sobre Cloud Code, las configuraciones que necesitan para aplicar esta tecnología de manera controlada y adecuada. Y además, vamos a hablar bastante sobre las habilidades que, al juntar todas estas partes, les permiten construir una plantilla completa que luego pueden aplicar a diferentes equipos y también a diferentes proyectos.

Cuando comienzas con esta tecnología, lo primero que debes hacer es agregar una instrucción inicial a Cloud Code. Todos comenzamos de esta manera, pero nos damos cuenta de que después de pasar muchas instrucciones, Cloud Code, comienza a perder un poco el enfoque y empieza a hacer cosas que no debería estar haciendo dentro de nuestra base de código. Y es por eso que también comenzamos a agregar diferentes componentes. En este caso, podemos agregar MCPs, que son básicamente conexiones con aplicaciones o con texto externo dentro de nuestro proyecto. Y de esta manera, podemos ejecutar algunas acciones que están fuera O incluso extraer información de diferentes APIs, diferentes bibliotecas, e inyectarlas en la ventana de contexto de Cloud Code usando varios MCPs.

Además de todo esto, también debemos agregar que podemos establecer diferentes configuraciones. Eso significa que podemos controlar los permisos que Cloud tiene para ejecutarse dentro de nuestra base de código. Y además, podemos darle permisos para ejecutar algunas herramientas de ciertos MCPs. O incluso podemos configurar Cloud Code para tener diferentes modos de trabajo dentro de nuestro proyecto, habilitando el modo automático o habilitando el modo plan. Esto hace que el archivo settings.json sea extremadamente importante, y necesitamos usarlo en diferentes proyectos.

Además de eso, hay algunos comandos que son repetitivos y que básicamente tomamos y colocamos en ciertos archivos para que el equipo pueda implementarlos, y así no tengamos que repetir la misma instrucción una y otra vez. Creamos estos comandos, y de esta manera podemos llamarlos y ejecutarlos cuando los necesitemos durante el ciclo de desarrollo. Hasta ahora, ya hemos incluido bastantes componentes en todo este proceso. Pero no se preocupen, porque todavía quedan algunos más por agregar.

A esto, debemos añadir los sub-agentes, que son básicamente una forma de dividir el contexto principal en diferentes procesos, donde estos sub-agentes explorarán la base de código, realizarán ciertas tareas y luego regresarán al contexto principal. Son extremadamente útiles y efectivos para trabajar con bases de código masivas y complejas. Estos sub-agentes especializados son utilizados constantemente y de manera consistente por Cloud Code, que es el agente principal, para explorar, analizar y ejecutar varios comandos en segundo plano.

Y finalmente, llegamos a las habilidades, que son una forma de inyectar grandes cantidades de contexto en el contexto principal. Pensemos en ellas como una especie de diccionario o documentación para los agentes de IA. Pueden ir y buscar diferentes documentos dentro de estas habilidades, y eso es bastante poderoso, porque podemos cargar un enorme conjunto de documentación de diferentes bibliotecas, o incluso podemos darle algunos procesos para que los agentes los ejecuten. Y de esta manera, tenemos una plantilla de desarrollo completa que el Cloud Code debería usar. Tenemos instrucciones iniciales, MCPs, configuraciones, comandos, sub-agentes y habilidades. Todo esto junto forma una plantilla, y deberíamos reutilizarla en diferentes proyectos.

Hay muchas maneras de compartir estos componentes. Y hoy, voy a mostrarles la forma en que Anthropic y la comunidad de Cloud Code han estado construyendo una biblioteca de plugins o una biblioteca de componentes con mejores prácticas para que los desarrolladores puedan tomar estos procesos y ejecutarlos en sus propios proyectos. Esto se llama harness engineering. Cuando ya tenemos tantos enfoques de desarrollo centrados en agentes, en realidad se convierte en una disciplina de ingeniería en sí misma. Todos estos conceptos son parte de este harness, que básicamente se trata de establecer un alcance de trabajo para que el Cloud Code, o todos los agentes de IA que trabajan dentro de la base de código, puedan tener control y rieles específicos para ejecutar sus tareas. Y todo esto va de la mano con la observabilidad y luego mejorando los procesos con los que estamos trabajando.

Una vez que un agente ha completado una tarea, necesitamos revisar los registros usando open telemetry y luego ver cómo podemos mejorar el proceso que este agente acaba de llevar a cabo. Hay muchas maneras de hacer este proceso, y hoy, voy a mostrarles una de las más básicas. Y es la que uso todo el tiempo en mis proyectos. Antes de llegar al punto en el que realmente podemos comenzar a configurar estos diversos procesos y controles para los agentes, necesitamos ser excepcionalmente claros y precisos sobre los diferentes niveles de configuración que estamos implementando y aplicando directamente a los agentes dentro de nuestro entorno organizacional específico.

Tenemos el nivel de usuario, que se aplicará a todos los proyectos en nuestra computadora. Es simplemente cuestión de agregar todas estas configuraciones a la raíz de nuestro proyecto. También tenemos la configuración a nivel de proyecto, que básicamente significa agregar estas mismas configuraciones dentro de nuestro repositorio para que de esta manera, se compartan con todo nuestro equipo.

Y finalmente, tenemos el nivel de empresa u organizacional, que básicamente significa dar toda la configuración a un administrador. Y luego este administrador a nivel organizacional comienza a agregar estas configuraciones para que se apliquen dentro de nuestros proyectos y dentro de nuestras configuraciones locales.

El primer archivo, y uno de los más importantes que debes tener en cuenta en Cloud Code, es settings.json. Este archivo te permitirá guardar variables de entorno, atributos, permisos, todas las configuraciones de MCP. Incluso puedes configurar diferentes procesos, por ejemplo, con hooks. Aquí, podemos ver que los hooks tienen un uso pretool y un uso post tool.

Eso significa que cada vez que Cloud Code ejecuta una herramienta dentro del proceso de su ventana de contexto, podremos ejecutar código, ya sea en batch o Python, para que este código se ejecute antes o después de que se ejecute esa herramienta. Y eso ya nos da una amplia variedad de opciones poderosas para ejecutar varios procesos esenciales de limpieza y optimización para nuestro proyecto. E incluso podemos realizar una verificación exhaustiva del código específico que Cloud Code acaba de escribir para ver si realmente lo hizo correctamente o si introdujo algún error o equivocación inesperada. Aquí es donde los proyectos pueden volverse deterministas, porque los agentes de inteligencia artificial simplemente no lo son. Y muchas veces, van a cometer errores.

Debemos tener en cuenta que podemos ejecutar hooks para que estos errores se minimicen tanto como sea posible. Y aquí es donde podemos crear algunas plantillas y configuraciones para que todo el equipo pueda ejecutarlas dentro de los procesos de ejecución de agentes que están limpiando o trabajando dentro de nuestra base de código. También tenemos líneas de estado, que son básicamente el área en la parte inferior de la entrada que se muestra dentro de Cloud Code. Y hay muchas otras configuraciones, por ejemplo, estilos de salida, spinners. Estas son cosas que puedes compartir con el equipo o no. Pero recomiendo que leas cada campo disponible en el settings.json para que sepas cuáles debes compartir con el equipo y cuáles puedes configurar tú mismo. Otro archivo muy importante es cloud.

md. Este archivo será el archivo principal de tu proyecto. Lo primero que hará es verificar este archivo.

Y entenderá tu proyecto revisando y leyendo cada palabra que aparece aquí. Este archivo está en Markdown, por lo que podemos revisarlo nosotros mismos como humanos. Y es bastante fácil de leer, y por eso. Recomiendo que siempre leas y actualices el archivo cloud.md. Puede tener algunos comandos de ejecución, o puede incluir todo el directorio del proyecto. Sugiero que lo configures siguiendo las mejores prácticas compartidas por la comunidad. Y también puedes adoptar todas las mejores prácticas enseñadas por el equipo de Cloud Code.

Cada vez que lo actualizan con nuevos modelos, este archivo es clave. Si lo tienes, ya tienes un gran porcentaje de la configuración de tu proyecto hecha, ya que cloud es el archivo principal que siempre se leerá. Y ahora pasemos a las habilidades. Este archivo, skill.md, está dividido en dos secciones. La primera es YAML, y la segunda es Markdown. Vamos a repasar cada una de estas secciones en esta charla. En esta demostración, podemos ver claramente cómo la habilidad específica se inyecta automáticamente en una sesión activa de cloud cada vez que el usuario hace una solicitud detallada que está directamente relacionada con la habilidad única de esta habilidad en particular. Justo al inicio de cada nueva sesión, cloud buscará cuidadosamente todas las habilidades disponibles que se encuentran actualmente dentro de la carpeta de habilidades específicas de tu proyecto.

Y de esta manera específica, cloud sabrá claramente que puede usar efectivamente estas habilidades especializadas cada vez que el usuario hace una solicitud directa que está específicamente relacionada con esta habilidad en particular. En este ejemplo, podemos ver que todas las habilidades se inyectan al inicio de la sesión, y luego cuando el usuario hace una solicitud, por ejemplo, para crear un PDF, cloud llamará a la habilidad de PDF e inyectará todo el contexto del archivo cloud.md para que el PDF que el usuario está pidiendo pueda ser creado. Y también es muy importante que cloud pueda llamar a archivos de referencia que están dentro de la habilidad. Ahora, déjame contarte un poco más sobre cómo funciona este mecanismo. Pero para comenzar con una habilidad, lo primero que necesitas hacer es crear el nombre y la descripción. Estos dos campos se inyectarán en la ventana de contexto, y cloud sabrá que hay una habilidad que, por ejemplo, en este caso, está configurando una reunión standup. Y de esta manera, cuando el usuario solicita crear el standup para la semana o el día, cloud llamará a esta habilidad y mirará la descripción. Es muy importante que la descripción sea perfecta para que cloud sepa cuándo llamar a este tipo de habilidad.

Y le estamos diciendo a cloud directamente que lo use cuando el usuario pida configurar un standup o el plan o la planificación para el día o la semana. Una vez que hemos creado el YAML inicial, necesitamos escribir las instrucciones. Y eso se hace en formato markdown. Eso es realmente genial porque podemos leer este formato y de esta manera, podemos entender lo que cloud está haciendo. Así que el formato markdown es muy fácil de entender y captar tanto para humanos como para agentes.

La configuración de front matter más fundamental que necesitas establecer dentro de una habilidad se compone esencialmente tanto del nombre específico como de la descripción detallada. Pero si queremos hacer algo un poco más avanzado, hay diferentes campos que podemos agregar a este front matter. Por ejemplo, cuándo usarlo. Este campo de descripción específica es absolutamente perfecto para incluir una descripción contextual detallada de exactamente cuándo necesitamos pasar la instrucción a cloud. Así sabe precisamente cómo y cuándo ejecutar y llamar efectivamente a esta habilidad específica.

También tenemos los argumentos. Cada vez que inicias una habilidad específica usando el comando de barra diagonal, puedes proporcionar argumentos y parámetros adicionales a este archivo que cloud luego inyectará automáticamente directamente en la habilidad. Al utilizar la función de argumento hence, podrás aprovechar la funcionalidad de autocompletar cada vez que llames a este comando específico. Además, con el campo de argumento, puedes pasar de manera conveniente y directa el nombre del argumento para inyectar sin problemas ese valor específico en el contexto de las habilidades. Te voy a mostrar cómo funciona ese tipo de instrucción.

También tenemos la desactivación de la invocación del modelo. Al utilizar este campo de configuración específico, se te da la capacidad de desactivar el modelo para que no invoque la habilidad, lo que significa efectivamente que puedes desarrollar e implementar habilidades que solo sean invocadas por el usuario usando el campo de invocación por el usuario, o puedes optar por desactivar manual y directamente el modelo para que nunca invoque esta habilidad en particular. De esta manera específica, es mucho más fácil configurar flujos de trabajo de agentes complejos porque sabemos claramente que hay algunos flujos específicos que los modelos mismos necesitan invocar durante la conversación. Y luego hay otros flujos distintos que el usuario debe invocar manualmente durante el curso de la conversación.

Así que cuando estás en el proceso de usar y crear nuevas habilidades para tu equipo, es importante pensar cuidadosamente si necesitas hacer que esa habilidad sea auto-invocable por el propio modelo, o si en su lugar debería ser invocable manualmente por el usuario humano. Además de eso, también tenemos disponible el campo de herramientas permitidas, y este campo específico te permite agregar varias herramientas específicas que Claude puede usar dentro del contexto de esa habilidad. Este campo es muy importante porque si no lo agregas, Claude usará todas las herramientas que tiene disponibles para ejecutar la habilidad. Eso significa que si tienes MCPs, es posible que una herramienta de uno de estos MCPs pueda ser inyectada en el flujo que creaste y que no formaba parte de tu plan o proceso original para la habilidad.

Así que siempre recomiendo agregar las herramientas específicas que están permitidas para ejecutar las habilidades que estás creando. También podemos agregar el modelo, esfuerzo y contexto. Cuando se trata de agregar el modelo, podrías preguntarte, ¿necesito un modelo que pueda razonar? ¿Necesito un modelo que sea realmente bueno ejecutando tareas? ¿O solo necesito un modelo que sea muy estructurado y pueda manejar una tarea muy básica y simple? Si necesitas un modelo que pueda hacer razonamientos profundos porque la habilidad resuelve un problema importante, recomiendo agregar el modelo Opus. Si necesitas un modelo que simplemente ejecute una tarea muy bien categorizada y diseñada dentro de la habilidad, pero que también explore y realmente entienda lo que estás haciendo, recomiendo agregar el modelo Sonnet. Y si ya tienes un flujo de trabajo muy básico y fácil de ejecutar, por ejemplo, agregar un mensaje a un commit o agregar mensajes a tus PRs, recomiendo usar el modelo Haiku.

Es mucho más barato, mucho más simple y más básico de usar. Y además de eso, es muy rápido. Así que piensa cuidadosamente cuando estés creando tus habilidades sobre qué modelos deberían usarse en este proceso. También puedes agregar el campo de esfuerzo. Este campo permite un razonamiento mucho más avanzado. Por ejemplo, si combinas el modelo Opus con un campo de esfuerzo configurado en alto o máximo, el razonamiento será muy avanzado y muchos agentes se activarán para trabajar dentro de este proceso. Si estás realizando un proceso muy básico, recomiendo usar Haiku con el esfuerzo configurado en bajo. De esta manera, puedes mezclar y combinar diferentes formas de ejecutar una habilidad.

Es muy importante que cuando lo estés creando, sepas exactamente qué campos necesitas agregar a estos elementos dentro del YAML. Por ejemplo, aquí tenemos un YAML muy específico para crear un mensaje en Git. Justo aquí en la pantalla, tenemos el nombre específico, la descripción detallada y las diversas pistas o indicaciones. Aquí están las pistas reales, y verás que estas pistas se autocompletarán automáticamente cada vez que el modelo necesite invocar esta habilidad en particular. Ahora, voy a darte una demostración exhaustiva para mostrarte exactamente cómo funciona ese proceso en la práctica. En esta habilidad, te voy a mostrar cómo funcionan estos campos.

Por ejemplo, tenemos esta habilidad con este nombre, y tenemos esta descripción. Si queremos usarla sin los otros campos, simplemente tenemos que eliminarlos, y tendremos una descripción y un nombre limpios. Si queremos invocar la habilidad, tenemos que entrar en Cloud Gold y comenzar a escribir el nombre de la habilidad. Aquí, podemos ver que la habilidad no muestra ningún campo extra. Ahora, vamos a agregar el campo, pista de argumento. Vamos a eliminar los otros, y solo vamos a dejar este campo. Cuando ejecutamos la aplicación una vez más, ahora podemos ver claramente que tenemos todos los campos de pista específicos que acabamos de terminar de agregar dentro de la habilidad. Además, Cloud Code renderiza automáticamente cada una de las configuraciones que agregamos manualmente dentro de la interfaz de la habilidad. Ahora, necesitamos agregar los siguientes campos.

Por ejemplo, el campo de argumento. Y este argumento específico que estamos pasando aquí se puede llamar fácilmente dentro de la instrucción simplemente usando el símbolo de dólar. Es realmente fácil construir instrucciones cuando estás pasando argumentos dentro del YAML. Así que, ten en cuenta que cada vez que creas una habilidad, necesitas agregar las pistas y luego el argumento. Si vas a usarlo dentro de las pistas, descripciones. Por último, agreguemos los otros campos.

Ahora, te voy a mostrar cómo diferenciar entre cuando el modelo está invocando la habilidad y cuando lo está haciendo el desarrollador. Si navegas de regreso a la interfaz de Cloud y ejecutas el comando de habilidades específicas dentro del terminal, podrás ver una lista completa de cada habilidad actualmente en tu proyecto, así como las diversas habilidades que se han puesto a disposición globalmente. En este caso, las etiquetadas como usuario son globales, y las etiquetadas como proyecto están dentro de tu proyecto. También puedes ver los tokens que se utilizarán. En este caso, son solo los tokens de descripción, y puedes ver todas las descripciones y todos los tokens que ya se están utilizando, porque se están inyectando en la ventana de contexto de Club.

En esta sección específica de la interfaz, podemos observar claramente si la habilidad está específicamente vinculada a la cuenta de un individuo a nivel de usuario, o si funciona directamente durante el proceso de invocación del modelo en sí para comprender mejor el alcance de la aplicación de habilidades. Ahora que hemos guardado y agregado este campo, veamos qué cambió. Habilidades de nuevo, y ahora podemos ver que solo es invocada por el usuario aquí. Dice solo usuario. En este caso, estamos haciendo que solo el usuario pueda invocar la habilidad. Si eliminamos este campo, veremos que esto cambiará. Ejecutamos la habilidad de nuevo, y ahora podemos ver que solo usuario no aparece, a diferencia de en esta habilidad aquí. En este caso, no aparece, y eso significa que puede ser invocada tanto por el usuario como por el modelo. El modelo también puede invocarla. Y finalmente, esta habilidad solo tiene permitido usar las herramientas por lotes, y también está ejecutando el modelo Haiku con bajo esfuerzo.

Ahora, podrías preguntarte por qué es así. Como mencioné anteriormente, esta habilidad en particular está específicamente diseñada con el propósito de elaborar un mensaje dentro de un commit. Eso significa que no necesariamente requerimos el uso de un modelo de razonamiento poderoso y de alto nivel como Opus, y tampoco necesitamos un modelo muy especializado para estos ciertos tipos de tareas, un poco más centrado en la programación y el desarrollo dentro de la base de código. Ten esto en cuenta. Puede ahorrarte muchos tokens.

Ahora que ya tenemos una idea general de cómo construir habilidades de manera tanto básica como más avanzada, necesitamos tener en cuenta la ventana de contexto. Si gestionamos bien la ventana de contexto en cada una de las sesiones que tenemos con nuestros agentes, podemos entender cuándo y cómo necesitamos inyectar estas habilidades. En este caso, CLAUD, gestiona el prompt del sistema, el cloud.md, el historial de la conversación, y los términos que están dentro de la sesión, iterando con CLAUD y todos los agentes, además de las herramientas que están ejecutándose y el resultado de cada una de estas escuelas.

Y también, los archivos que CLAUD lee para inyectar contexto en toda esta ventana. Y finalmente, tenemos un espacio donde podemos agregar contexto, ya sea manualmente o con habilidades o subagentes, o diferentes maneras de proporcionar más contexto dentro de la sesión. Aquí, podemos ver un flujo típico de una habilidad llamando a diferentes archivos.

La habilidad no es solo la materia y el markdown. La habilidad también tiene referencias que puede llamar si necesita usar otras fuentes de información que estarán dentro de la carpeta. En este caso, la habilidad PDF está llamando a esta referencia de archivo .md e inyectando todo el contexto de este archivo. También está llamando a otro archivo, que es form.md. Y también lo está inyectando en esta ventana de contexto para obtener más información según la solicitud del usuario. Las habilidades pueden llamar a muchos archivos, pero ten en cuenta que también pueden llamar a archivos que son scripts.

Y cuando llama, un script puede leer este archivo o simplemente ejecutarlo. Y esto es muy poderoso porque podemos tener muchos scripts dentro de nuestra habilidad. Y solo CLAUD leerá la salida de estos scripts. Esto significa que podemos ejecutar muchos procesos internos y CLAUD podrá obtener el resultado de todas estas ejecuciones. También podemos tener referencias a muchos archivos markdown o cualquier otro tipo de archivo. CLAUD leerá estos archivos y los inyectará directamente en el contexto.

Recomiendo que las referencias estén en markdown, porque también tienes que leerlas y necesitas estar al tanto de toda la información que estás inyectando en el proceso de habilidades. Y finalmente, podemos agregar recursos adicionales. En este caso, pueden ser archivos TXT o cualquier tipo de archivos que necesites agregar dentro de los procesos de habilidades. Aquí podemos ver un ejemplo donde estamos ejecutando este archivo en Python.

Python podrá leer la salida. No leerá absolutamente toda la información del script en este archivo. Y aquí podemos ver que CLAUD leerá el archivo directamente. El verbo es muy importante. Aquí le estamos diciendo que ejecute este archivo y aquí le estamos diciendo que lea este archivo.

Finalmente, ahora podemos entender cómo funciona todo el flujo. El contexto que vimos al principio, donde la habilidad fue inyectada al inicio de la sesión, ahora lo entendemos y sabemos cuándo sucede. El modelo llamará a cada habilidad ya sea automáticamente o manualmente. ¿Y cómo navegarán a través de todas las referencias y los scripts que tiene esta habilidad, que acabas de juntar, y que es un proceso interno que debes gestionar para ejecutar?

Aquí, estoy compartiendo contigo algunas habilidades que están increíblemente bien hechas. Matt creó esta habilidad. Es uno de los ingenieros más influyentes en el campo de JavaScript. Así que te recomiendo que la revises y pruebes ejecutarla. Pero lo más importante, te recomiendo que vayas al GitHub de Matt y leas toda la habilidad. Compartió todos los procesos y todo el flujo de trabajo que está creando con sus habilidades.

Él compartió todos los procesos y todo el flujo de trabajo que está creando con sus habilidades. Esta es otra habilidad muy importante porque está hecha por la misma empresa que creó Cloud Code, que es Anthropic. Y también, ¿cuáles son los procesos que se están aplicando dentro de las instrucciones de habilidades?

Y finalmente, esta habilidad. La he estado usando ya que funciona muy bien con tus proyectos de JavaScript y funciona bastante bien con absolutamente todos ellos. Ya sea Cloud Code, Codex, AntiGravity, Cursor, GitHub Copilot, u OpenCode. Te recomiendo que revises aún más habilidades visitando este sitio web. Hice este sitio web yo mismo, y se llama Cloud Code Templates.

Puedes ir a esta dirección y podrás ver una gran cantidad de habilidades. Y la mejor parte es que podrás leer las habilidades para entender cómo la comunidad está construyendo estas habilidades y cómo están funcionando en muchos proyectos. También podrás ver cuántas descargas tiene cada habilidad. Y también están divididas en habilidades, agentes, comandos, configuraciones, hooks, y MCPs. Echa un vistazo a esta página. La creé yo mismo, y ha funcionado muy bien para mí. La he estado usando para muchos proyectos.

Muchas gracias. Una vez más, estoy compartiendo mis redes sociales, para que puedan ver todo lo que he estado publicando y todos los artículos y blogs que comparto diariamente con toda la información que estoy aprendiendo. Espero que esta charla haya sido útil, y nos vemos por ahí. Muchas gracias a todos.

Hola a todos. Y bienvenidos de nuevo. Hola, Daniel. Hola, chicos. Muchas gracias por tu charla. Es muy significativa e importante. Creo que todos nosotros, como ingenieros de software, empezamos a ver que incluso en las empresas más grandes, esas mejores prácticas comienzan a aparecer y centralizarse. Muchas gracias desde tu perspectiva por ayudar en la otra dirección, desde el punto de vista de la comunidad. Trabajo increíble, y muchas gracias por tu charla.

Solo quiero recordarles que si quieren hacerle una pregunta a alguien, a nuestros ponentes, por favor únanse a Slido.com y usen el número 0607 para AI Core Coding Summit hoy. Y pregunten cualquier cosa a nuestros ponentes hoy. Mientras esperamos que aparezcan más preguntas, ya tenemos algunas de ellas, tal vez comience con mi propia pregunta. Eso es respecto a tu famoso repo y básicamente tu experiencia con las actividades allí. ¿Ves muchos agentes contribuyendo o es más como personas? ¿Cuál es tu experiencia con GitHub hasta ahora? Creo que ahora mismo todo son agentes. Nadie está escribiendo código. Nadie está escribiendo habilidades. Todo es Cloud Code o Codex. Así que esa es la razón por la que necesitamos revisar cada solicitud de extracción de nuestro repo. Pero ahora mismo tenemos dos tipos de contribuciones. La primera es gente simplemente compartiendo habilidades, compartiendo MCPs, compartiendo hooks. Muchas empresas que quieren compartir diferentes APIs y MCPs. Y el otro tipo de contribución son los loops. Así que hay muchos loops ejecutándose en el repo, mejorando diferentes habilidades. Así que todo lo que ya les mostré está relacionado con loops, habilidades, y agentes tratando de compartir más datos en el repo. Así que es un poco difícil tratar de mantener todo bajo control, todo en mi repo ahora mismo. Pero tengo como cinco agentes ejecutándose y revisando cada solicitud de extracción.

Así que creo que ahora mismo estoy haciendo un buen trabajo tratando de mantener todo relacionado con el repo y trabajando con toda la contribución que estoy teniendo.

Sí, veo. Veo muchos agentes contribuyendo hoy en día. Bueno, hay algunas preguntas, como dije, ya en la cola.

Comencemos con la primera. Por Alejandro y gracias por iniciar sesión, de hecho, en el sistema. Es un poco técnico, pero creo que es interesante desde tu perspectiva.

¿Cuándo debería usar un sub-agente versus una skill usando ContextFork? Sí, esa es una muy buena pregunta porque el ContextFork es confuso.

Entonces, cuando necesitas bifurcar tu contexto y tratar de trabajar con un contexto diferente. Así que en este caso, cuando usas un sub-agente, es porque no necesitas todo el contexto en tu contexto principal.

Necesitas que ese sub-agente trabaje en una sesión diferente, en un contexto diferente. Así que en este caso, necesitas usar un sub-agente. Puedes simplemente crear un nuevo sub-agente, ejecutar con diferentes skills, y simplemente obtener la salida de ese sub-agente.

Así que todo depende de cuál es tu tarea. ¿Qué estás tratando de lograr con esta skill o con este sub-agente? Así que todo depende de lo que quieras ejecutar y cuál es tu ventana de contexto, cuál va a ser tu modelo. Hay muchas cosas que necesitas pensar antes de ejecutar este tipo de agente o skills de sub-agentes. Pero en este caso, si necesitas todo en otra sesión, en otro contexto, necesitas usar el fork y simplemente ejecutar eso en otra sesión con más datos y simplemente obtener la salida de ese sub-agente. Anotado.

Gracias. Y continuamos con otra pregunta de Alejandro, de hecho.

También va en esa dirección. Es más sobre cómo cambiar skills o componer skills dependiendo de una tarea concreta.

¿Sugerirías algo? Nuevamente, ¿qué estás tratando de lograr con tu tarea?

En este caso, cada skill que vas a construir, puedes crear referencias, puedes crear scripts, puedes crear activos para tu skill. Así que la mejor manera de hacerlo depende de si vas a ejecutar esta tarea y cuál es tu ventana de contexto. Si estás ejecutando un agente aislado, estará con una ventana de contexto, y no necesitas pensar mucho en eso. Pero si estás ejecutando en Telco, por ejemplo, tienes que pensar que ya tienes una sesión completa con más contexto, con toda tu base de código.

Así que todo va a estar en tu ventana de contexto. Necesitas crear tu skill.md lo más pequeño posible. Si tienes un skill.md realmente pequeño, puedes comenzar a crear diferentes referencias con más datos, y puedes crear diferentes scripts con más datos, y luego puedes comenzar a crear este cambio de prompts para obtener más datos. Y necesitas pensar en tu skill.md como un índice.

Así que si tienes ese índice realmente bueno para obtener y recuperar estos datos de tu referencia, eso va a ser una skill realmente buena porque puedes ejecutarla en tu sesión completa, y puedes comenzar a crear diferentes tareas para esa skill. Gracias. Creo que eso cubre otra pregunta que estaba relacionada con el CloudMD sin aumentar demasiado la ventana de contexto.

Pero si quieres agregar algo a esa pregunta, por favor adelante mientras también respondes otra pregunta sobre CloudMD. ¿Sería más eficiente transferir las reglas y directrices de CloudMD a skills en lugar de mantenerlas en reglas y usar skills para validar y aplicar reglas? Sí. Así que CloudMD es algo que siempre necesitas en cada solicitud que vas a hacer a los LLMs. Así que piensa que cada vez que preguntas algo a tu LLM, vas a necesitar esos datos en tu solicitud.

Y la skill es solo una tarea específica con ese principio y fin. Así que si tienes una tarea que estás haciendo en cada sesión y necesitas repetir para más personas en tu equipo, necesitas moverla de tu Cloud.MD y crear una skill para eso. Algo que necesitas compartir con tu equipo. Algo que necesitas compartir con más personas. Eso va a ser una skill.

No necesitas esos datos en tu Cloud.MD porque vas a estar agregando más datos a tu ventana de contexto y necesitas que tu ventana de contexto sea lo más pequeña posible para ejecutar toda tu base de código y toda tu sesión. Así que piensa en tu Cloud.MD como algo que – es como directrices que necesitas agregar a tu sesión. Algo simple, algo que siempre necesitas recordar en cada solicitud. Y piensa en tu skill como algo que – es solo una tarea en una sesión específica, es una tarea específica que tienes.

Y necesitas crear esta skill para compartir en tu equipo. Estoy usando una skill solo para compartir tareas con mi equipo. No soy muy bueno en frontend, así que necesito más skills del equipo de frontend en mi equipo. Pero estoy compartiendo muchas skills de infra.

Todo lo relacionado con Cloud, lo estoy compartiendo con todo mi equipo porque soy el experto en ese concepto específico. Entendido. Claro.

La siguiente pregunta es sobre la galicinación de LLM's. Hay observación de que cuando la ventana de contexto está a punto de completarse, el Cloud comienza a galicinar. Asumiría que ya existen mejores prácticas para resumir el hilo y comenzar uno nuevo. ¿Cuál es tu consejo sobre eso? ¿Cuál es tu opinión? Creo que esa es la razón por la que seguimos trabajando en este arnés. Esa es la razón por la que estamos creando las skills, esa es la razón por la que estamos creando algunos agentes. Y esa es la razón por la que necesitamos leer cada skill que creamos. Es muy difícil porque estaba escribiendo código, estaba leyendo código durante los últimos 15 años. Y ahora mismo estoy leyendo y escribiendo skills, archivos markdown. Así que todo mi día es leer archivos markdown y crear un script para ejecutar en estas skills. Así que creo que necesitamos seguir trabajando en esto. Es una etapa muy temprana en este momento. Y necesitamos seguir mejorando los LLM's y también la skill que ejecutamos sobre estos LLM's. Así que ahora mismo es algo que no podemos manejar demasiado porque Entropiq, OpenAI, están construyendo estos LLM's. Y cada vez que tenemos un nuevo LLM, un nuevo modelo, podemos mejorar las skills y podemos ejecutar diferentes evals. Pero ese es mi consejo. Necesitas ejecutar evals. Necesitas seguir leyendo estas skills que tienes y mejorar con nuevos modelos. Entendido. Genial.

Creo que tal vez tengamos tiempo para una última, tal vez las últimas dos preguntas. Bueno, la primera, alguien está preguntando, tal vez como un resumen, ¿qué sugerirías usar MCP versus CLI? ¿Cuál es la elección correcta para la tarea? Sí, esa es una muy buena pregunta. Y ahora mismo tenemos ambos. Tenemos CLI y tenemos MCPs en nuestro trabajo. Estoy usando mucho CLI. Cloud code es increíble. Así que CLI es realmente bueno para crear una tarea diferente en tu trabajo. Pero MCP, creo, es el futuro ahora mismo porque no todos los usuarios y personas saben qué es un CLI. Así que si necesitas compartir tu trabajo con más personas, personas no técnicas, necesitas un MCP. Y necesitas crear tu MCP porque la gente va a ejecutar estos en chat GPT, en Cloud, no en el Cloud code. Así que van a usar Cloud Chat.

Van a usar chat GPT. Y si quieres compartir con más personas, no técnicas, con todo el mundo tu trabajo, necesitas un MCP. Porque es una muy buena manera de compartir tus APIs, tu trabajo y conectar con tu plataforma. Ahora mismo tenemos ambos. Así que necesitas pensar en personas técnicas. CLI es realmente bueno. Personas no técnicas, MCP es realmente bueno.

Muy bien. Muy bien. Eso está muy claro. Creo que terminaremos con eso. Daniel, muchas gracias por tu proyecto. Es increíble. Buena suerte con el viaje futuro y disfruta de la conferencia.

Sí. Muchas gracias.