LangChain ha recaudado 160 millones de dólares. Tres años de desarrollo. Una valoración de mil millones de dólares. LangSmith, su plataforma de pruebas, es genuinamente sofisticada: evaluaciones de trayectoria, pipelines de traza a conjunto de datos, LLM como juez, suites de regresión, marcos de pruebas unitarias para herramientas. Tienen las piezas. Crédito donde se debe.
Pero las piezas no son una práctica.
LangChain te da herramientas de prueba. Nunca te dice qué probar, en qué orden ni cuándo has terminado.
No existe un flujo de trabajo opinado que indique, en orden:
- ocurrió este error
- ahora escribe una habilidad (skill)
- ahora escribe el código determinista
- ahora escribe pruebas unitarias
- ahora escribe evaluaciones LLM
- ahora agrega un disparador de resolución
- ahora evalúa la resolución
- ahora audita duplicados
- ahora haz una prueba de humo
- ahora archiva correctamente
Ese bucle no existe. Tienes que inventarlo tú mismo a partir de primitivas dispersas. Muchos usuarios de IA todavía no prueban sus agentes en absoluto, porque el framework que eligieron probablemente les dio una membresía de gimnasio sin un plan de entrenamiento.
La mayor parte de la "confiabilidad" de los agentes de IA se basa en vibraciones. Ajustes de prompt. Mensajes del sistema más grandes. Conjuros de "por favor no alucines". Eso se degrada en cuanto la conversación se vuelve compleja. Los frameworks que recaudaron cientos de millones de dólares para resolver esto te dieron paneles de monitoreo y ayudantes de pruebas unitarias y dijeron "buena suerte".
Mi agente se equivocó dos veces esta semana. Ninguno de esos errores puede volver a ocurrir. No porque lo pedí amablemente. Sino porque convertí cada error en una solución estructural permanente: una habilidad con pruebas que se ejecutan todos los días, para siempre.
A esto lo llamo la práctica "skillify". Una vez que la usas, tus agentes dejarán de cometer los mismos errores. Así es como funciona.
Error 1: El viaje que ya estaba en la base de datos
Le pregunté a mi OpenClaw sobre un viejo viaje de negocios, de hace casi diez años, enterrado en algún lugar del historial del calendario. Pregunta simple. Debería tomar un segundo.
En cambio, el agente hizo esto:
- Llamó a la API del calendario en vivo → bloqueado (demasiado atrás).
- Intentó búsqueda en correo electrónico → resultados ruidosos, nada concluyente.
- Intentó la API del calendario nuevamente con diferentes parámetros → aún bloqueado.
- Cinco minutos después, buscó en mi base de conocimiento local y lo encontró al instante.
La respuesta había estado en mis propios datos todo el tiempo. 3.146 archivos de calendario que abarcan desde 2013 hasta 2026. Ya indexados. Ya locales. A un grep de distancia.
El agente simplemente no miró allí primero.
En el framework del que he estado escribiendo (thin harness, fat skills) existe una distinción clave entre el trabajo que requiere juicio y el trabajo que requiere precisión. Los llamo latente y determinista. El grep del calendario es determinista. Misma entrada, misma salida, siempre. No se necesita modelo. Pero el agente lo hizo en espacio latente de todos modos, generando razonamiento, haciendo llamadas API, interpretando resultados, cuando un script de tres líneas habría devuelto la respuesta al instante.
Ese es el error. No una respuesta incorrecta. Un lado incorrecto.
La solución: calendar-recall (Pasos 1 + 2)
En thin harness / fat skills, una habilidad (skill) es un procedimiento en markdown que le enseña al modelo cómo abordar una tarea. No qué hacer (el usuario proporciona el qué). La habilidad proporciona el proceso. Piénsalo como una llamada a método: el mismo procedimiento, resultados radicalmente diferentes según lo que se pase.
Aquí está la habilidad que surgió de este error:
name: calendar-recall description: "Brain-first historical calendar lookup. ALWAYS use this before any live API for any event not in the future or the last 48 hours."
Y la regla interna:
Live calendar APIs are ONLY for events in the FUTURE or the LAST 48 HOURS. Everything historical goes through the local knowledge base first.
Esto es lo que hace que funcione: el agente mismo escribió el script determinista. El archivo de habilidad (markdown, viviendo en espacio latente) le dijo al agente cómo solucionar el problema. El agente leyó la habilidad, entendió que la búsqueda en calendario es trabajo determinista y generó un script para manejarlo:
$ node scripts/calendar-recall.mjs search "Singapore"
Found 2 matching day(s): ── 2016-05-07 ── Flight to Singapore, Mandarin Oriental check-in ── 2016-05-08 ── Lunch with investors at Fullerton Hotel
Código que se ejecuta en menos de 100 milisegundos (la mayor parte es el inicio de Bun; el grep real es inferior a un milisegundo). Cero llamadas LLM. Cero red. Solo archivos locales.
Este es el bucle que hace funcionar toda la arquitectura: el espacio latente construye la herramienta determinista, luego la herramienta determinista restringe el espacio latente. El agente usó juicio (latente) para escribir calendar-recall.mjs. Ahora la habilidad obliga al agente a ejecutar ese script en lugar de razonar sobre los datos del calendario. La inteligencia del modelo creó la restricción que evita que el modelo sea estúpido.
La ruta de error anterior se vuelve estructuralmente inalcanzable. La habilidad dice "busca local primero". El script realiza la búsqueda. El agente nunca tiene la oportunidad de ser ingenioso al respecto o volver a equivocarse.
Error 2: "28 minutos" (Pasos 1 + 2 nuevamente)
Mismo día. El agente dice: "Tu próxima reunión es en 28 minutos".
Realidad: faltan 88 minutos. El agente había hecho el cálculo mental de UTC a hora del Pacífico y se equivocó por exactamente una hora.
El caso es que ya existía un script (context-now.mjs) que genera esto:
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }
Código que se ejecuta en unos 50 milisegundos. Cero ambigüedad. El agente simplemente no lo ejecutó.
Misma forma que antes: trabajo determinista (restar marcas de tiempo) realizado en espacio latente. El modelo estaba haciendo cálculos mentales cuando un script tenía la respuesta.
La solución: context-now, la habilidad:
name: context-now description: "ALWAYS-ON discipline: run context-now.mjs before making ANY time-sensitive claim. Never do UTC→PT conversion in your head."
Aquí está el simple antes/después con y sin estas habilidades simples:
Skillify: El patrón que te salvará la cordura
Dos errores. Misma forma. El agente tenía la herramienta adecuada y eligió la astucia en lugar de la disciplina. Lo incorrecto ocurrió en el espacio de máquina equivocado.
En una configuración de IA normal, la IA se disculpará, prometerá hacerlo mejor y dos semanas después ocurrirá lo mismo con una consulta diferente o una zona horaria diferente. El agente no tiene memoria del error, ni prueba para el error, nada impide que se repita.
Skillify es la solución. Cada error se convierte en una habilidad. Cada habilidad tiene pruebas. El error se vuelve estructuralmente imposible de repetir.
Aquí está la lista de verificación de 10 elementos que uso cuando un error asciende:
□ 1. SKILL.md — el contrato (nombre, disparadores, reglas) □ 2. Código determinista — scripts/*.mjs (sin LLM para lo que el código puede hacer) □ 3. Pruebas unitarias — vitest □ 4. Pruebas de integración — endpoints en vivo □ 5. Evaluaciones LLM — calidad + corrección □ 6. Disparador de resolución — entrada en AGENTS.md □ 7. Evaluación de resolución — verificar que el disparador realmente enruta □ 8. Auditoría de resolubilidad + DRY □ 9. Prueba de humo E2E □ 10. Reglas de archivo en el cerebro (brain)
Una característica que no pase los diez no es una habilidad. Es solo código que funciona hoy.
Los dos errores anteriores ya recorrieron los pasos 1 y 2: escribir el SKILL.md (el contrato) y luego escribir el código determinista (el script que el agente construye y luego usa). Pero antes de recorrer los ocho pasos restantes, quiero mostrarte cómo se ve skillify en el uso diario, porque no es solo una respuesta al fracaso. Se convirtió en un verbo.
Skillify como verbo
Para mí, al construir mi OpenClaw (y GBrain), la lista de verificación comenzó como un protocolo de respuesta a errores. Luego se convirtió en la forma en que construyo todo.
Así es como se ve mi flujo de trabajo real. Estoy hablando con mi agente en lenguaje natural. Construimos algo juntos en la conversación. Lo pruebo. Funciona. Luego digo una palabra:
Garry:
carajo, funcionó. ¿puedes recordar esto como una habilidad de webhook y aplicarle skillify? La próxima vez que necesitemos webhooks. ¿Por qué fue tan difícil hacerlo bien? Bueno, ahora está bien. Hazlo DRY también
Esa fue una integración de webhook OAuth. Pasamos una hora haciéndolo funcionar. Luego "skillify it" convirtió la sesión ad-hoc en una habilidad duradera con pruebas, una entrada en el resolvedor y documentación. La próxima vez que necesite un webhook, la habilidad existe. El agente la lee. El conocimiento ganado con esfuerzo de esa hora es permanente.
Otro ejemplo. Descubrimos que nuestro contenedor necesita un navegador sin cabeza para ciertas tareas y un navegador con cabeza en mi escritorio para otras:
Garry:
¡genial! entonces deberíamos recordar esto como una habilidad cada vez que algo en openclaw necesite un navegador sin cabeza. Y también saber que si necesitamos un navegador con cabeza, debemos pedirle al usuario que ejecute gstack browser y nos dé un código de par de agente. ¡aplícale skillify!
Un mensaje. El agente escribe skills/browser/SKILL.md con el árbol de decisión, los scripts deterministas, las pruebas. Ahora cada sesión futura que necesite un navegador se enrutará automáticamente a la herramienta correcta.
O esto. Noté que el agente seguía enviándome enlaces de ngrok sin verificar si realmente funcionaban:
Garry:
¿podemos crear una habilidad que diga que cada vez que me envíes un enlace, debes hacerle un curl tú mismo para asegurarte de que el endpoint esté abierto y el túnel funcione? ¡aplícale skillify!
O la doble reserva en el calendario que casi me cuesta una reunión:
Garry:
Aquí hay una habilidad regular que necesito que escribas. Es la habilidad de verificación de calendario. Mañana tengo una doble reserva a las 11 a.m. Crea una habilidad, hazla determinista para verificar este tipo de cosas.
Una frase. Código, habilidad, pruebas, entrada en el resolvedor, auditoría de alcanzabilidad. La lista completa de 10 pasos en un solo aliento. Mi OpenClaw lo sabe, lo hace y ahora es un ritmo. Lo he hecho docenas de veces. No podría vivir sin ello.
El patrón es siempre el mismo: prototipo en conversación, veo que funciona, digo "skillify", y el prototipo se convierte en infraestructura permanente. No escribo especificaciones. No creo tickets. Hablo con mi agente, resolvemos el problema juntos, y luego la solución se convierte en una habilidad que el agente puede usar para siempre sin mí.
Esto es lo que se perdieron los 160 millones de dólares en financiación de frameworks. No las primitivas de prueba. No las herramientas de evaluación. El flujo de trabajo. El momento en que un humano dice "eso funcionó, ahora hazlo permanente" y el sistema sabe exactamente lo que significa "permanente": SKILL.md, código determinista, pruebas unitarias, pruebas de integración, evaluaciones LLM, disparador de resolución, evaluación de resolución, auditoría DRY, prueba de humo, archivo en el cerebro. Diez pasos. Una palabra.
Así es como se ven los ocho pasos restantes en la práctica.
Paso 3: Pruebas unitarias
Vitest clásico. Funciones deterministas, afirmaciones deterministas. calendar-recall.mjs exporta funciones puras como parseEventLine, eventMatchesKeyword, searchKeyword, formatJson. Cada una se prueba con datos de fixture: archivos de calendario sintéticos en un directorio temporal, entradas conocidas, salidas conocidas.
El tipo de error que detectan: parseEventLine elimina silenciosamente eventos con caracteres Unicode en el campo de ubicación. dateFromPath devuelve null para fechas bisiestas. formatJson omite el array de asistentes cuando solo hay una persona. Pequeños, aburridos, críticos. Si el script produce una salida incorrecta, la habilidad produce respuestas incorrectas y el agente me dice confiadamente algo incorrecto.
Para context-now, las pruebas unitarias verifican el formato de la zona horaria, la detección de horas de silencio y el cálculo de minutesUntil a través de los límites del horario de verano. Una prueba introduce una hora 3 minutos antes de un cambio de horario de verano y verifica que la salida no salte 60 minutos. Ese es exactamente el error que causó la falla de "28 minutos". Ahora es estructuralmente imposible.
Tengo 179 pruebas unitarias en 5 suites. Se ejecutan en menos de 2 segundos.
Paso 4: Pruebas de integración
Estas golpean endpoints en vivo y datos reales. ¿calendar-recall.mjs realmente encuentra eventos en el repositorio cerebral real, no solo en los fixtures de prueba? ¿context-now.mjs produce JSON válido cuando la caché del calendario está desactualizada o falta? Las pruebas de integración detectan los errores que las pruebas unitarias pasan por alto porque los datos de fixture eran demasiado limpios. Los datos reales tienen líneas de eventos mal formadas, campos de zona horaria faltantes, archivos de calendario con saltos de línea de Windows, eventos que abarcan la medianoche.
La regla: si te encuentras verificando manualmente si el script hizo lo correcto con datos reales, esa verificación debería ser una prueba de integración.
Paso 5: Evaluaciones LLM
Aquí es donde se pone interesante. Algunas salidas requieren juicio para evaluarlas. "¿Este resumen del calendario es útil?" no es una pregunta de sí/no que un script pueda responder. Así que uso LLM como juez: un modelo evaluando la salida de otro modelo contra una rúbrica.
Para context-now, se ejecutan 35 evaluaciones diarias. Una de ellas le da al agente un mensaje como "oye, mi vuelo sale en aproximadamente 45 minutos, ¿llegaré a SFO?" y verifica si el agente ejecuta context-now.mjs antes de responder o intenta hacer el cálculo mentalmente. Si el agente cae en la trampa y calcula la hora por sí mismo, la evaluación falla.
Otra evaluación le da al agente una marca de tiempo UTC y le pregunta "¿qué hora es esa para mí?". El comportamiento correcto es ejecutar el script y citar el resultado. El comportamiento incorrecto es hacer la conversión mentalmente. La evaluación detecta tanto la respuesta incorrecta como el proceso incorrecto, porque incluso si el cálculo mental resulta ser correcto esta vez, será incorrecto la próxima.
La heurística de evaluación más honesta que he encontrado: busca en tu historial de conversaciones las veces que dijiste "maldita sea" o "qué carajo". Esos son los casos de prueba que te faltan.
Paso 6: Disparador de resolución
Un resolvedor (resolver) es una tabla de enrutamiento para el contexto: cuando aparece el tipo de tarea X, carga la habilidad Y. Escribí sobre resolvedores en detalle aquí. Cada habilidad necesita una entrada de disparador en AGENTS.md, el archivo que le enseña al agente qué habilidades existen y cuándo usarlas.
Los disparadores de resolución son solo filas en una tabla de markdown:
El error que detecta este paso: escribes una nueva habilidad pero olvidas agregarla al resolvedor. La habilidad existe. La capacidad existe. El sistema no puede alcanzarla. Es como tener un cirujano en el personal pero no listarlo en el directorio del hospital. Peor que no tener la habilidad en absoluto, porque piensas que el sistema la maneja.
Paso 7: Evaluación de resolución
Esta es la capa que la mayoría de la gente pasa por alto por completo. Un disparador de resolución dice "esta frase debería enrutarse a esta habilidad". Una evaluación de resolución prueba que realmente lo hace.
Mi suite de evaluación de resolución tiene más de 50 casos de prueba como este:
{ intent: 'check my signatures', expectedSkill: 'executive-assistant' }, { intent: 'who is Pedro Franceschi', expectedSkill: 'brain-ops' }, { intent: 'save this article', expectedSkill: 'idea-ingest' }, { intent: 'what time is my meeting', expectedSkill: 'context-now' }, { intent: 'find my 2016 trip', expectedSkill: 'calendar-recall' },
Dos modos de fallo. Falso negativo: la habilidad debería activarse pero no lo hace, porque la descripción del disparador es incorrecta o falta. Falso positivo: se activa la habilidad incorrecta, porque dos disparadores se superponen. "¿Qué hay en mi calendario mañana?" debería enrutarse a calendar-check, no a calendar-recall ni a google-calendar. Tres habilidades, tres dominios de tiempo diferentes, una frase que podría coincidir plausiblemente con cualquiera de ellos. La evaluación de resolución detecta la ambigüedad antes de que un usuario la encuentre.
Ejecuto estas evaluaciones tanto como pruebas estructurales deterministas (¿la tabla de AGENTS.md contiene la asignación correcta?) como pruebas de enrutamiento LLM (dada esta intención, ¿el modelo realmente elige la habilidad correcta?). Ambas capas importan. La tabla puede ser correcta y el modelo aún puede enrutar incorrectamente porque la descripción del disparador es vaga.
Paso 8: Auditoría de resolubilidad + DRY
Después de un mes de construcción, tenía más de 40 habilidades. Algunas creadas en respuesta a incidentes específicos, otras generadas por subagentes ejecutando crons. Nadie mantenía la tabla de resolvedores. Las habilidades estaban naciendo pero no se registraban.
Así que construí check-resolvable. Una meta-prueba que recorre toda la cadena: resolvedor de AGENTS.md → SKILL.md → script/cron. Si existe un script que hace trabajo útil pero no tiene una ruta desde el resolvedor, es inalcanzable. El LLM nunca sabrá que debe usarlo.
La primera ejecución encontró 6 habilidades inalcanzables de más de 40. El quince por ciento de las capacidades del sistema estaban ocultas.
- Un rastreador de vuelos que nadie podía invocar preguntando sobre vuelos.
- Un generador de ideas de contenido que solo se ejecutaba en cron pero no podía activarse manualmente.
- Un corrector de citas que existía en el directorio de habilidades pero no estaba listado en el resolvedor en absoluto.
Arreglado en una hora. Solo agregué entradas de disparador a AGENTS.md. Ahora check-resolvable se ejecuta semanalmente como parte de gbrain doctor. Verifica tres cosas:
- Cada directorio de habilidad con un SKILL.md tiene una entrada correspondiente en el resolvedor.
- Cada script al que hace referencia una habilidad es realmente invocable (el archivo existe, exporta las funciones correctas).
- No hay dos habilidades con descripciones de disparador superpuestas que causen enrutamiento ambiguo.
La auditoría DRY se ejecuta junto con ella. Terminas con quince habilidades que más o menos hacen lo mismo si no tienes cuidado, y el resolvedor elige la que caiga. Para calendar-recall:
Cuatro habilidades en el mismo dominio. Cero superposición. Cada una tiene su carril. Esa matriz no es un diagrama dibujado para esta publicación. Vive dentro del SKILL.md, y el script de auditoría lo analiza. Construye una sexta habilidad de calendario que pise el carril de otra y la auditoría fallará antes de que la habilidad pueda enviarse.
Paso 9: Prueba de humo E2E
El pipeline completo, de extremo a extremo.
- Pregúntale al agente "¿cuándo fui a Singapur?" y verifica que ejecute calendar-recall.mjs, obtenga la respuesta correcta y la formatee correctamente.
- Pregunta "¿a qué hora es mi próxima reunión?" y verifica que ejecute context-now.mjs en lugar de hacer cálculos mentales.
Las pruebas de humo son la última línea de defensa. Todo lo demás puede pasar y el sistema aún puede fallar si las piezas no se conectan. La habilidad puede ser correcta, el script puede ser correcto, el resolvedor puede ser correcto, y el agente aún puede optar por ignorarlo todo y improvisar. La prueba de humo detecta eso.
Paso 10: Reglas de archivo en el cerebro (brain)
Cada habilidad que escribe en la base de conocimiento necesita saber dónde van las cosas. Una persona va en people/. Una empresa va en companies/. Un análisis de políticas va en civic/. Atrapé 10 de cada 13 habilidades de escritura en el cerebro archivando en el directorio incorrecto porque cada una había codificado sus propias rutas en lugar de consultar al resolvedor.
El documento de reglas de archivo cataloga patrones comunes de archivo incorrecto. Fuentes vs. originales. Personas vs. empresas (cuando alguien ES una empresa). La habilidad lee las reglas antes de crear cualquier página. Cero archivos incorrectos desde entonces.
GBrain: donde vive Skillify, y deberías adoptarlo desde mi GBrain Skill Pack
El patrón skillify no es específico de OpenClaw ni de ningún harness en particular. Está integrado en GBrain. GBrain es el motor de conocimiento de código abierto que escribí y que se encuentra debajo del harness que uses. Gestiona tu repositorio cerebral, ejecuta tus evaluaciones y hace cumplir los controles de calidad que hacen que las habilidades sean duraderas.
Un GBrain SkillPack es un paquete portátil de habilidades, disparadores de resolución, scripts deterministas y pruebas que puedes instalar en cualquier configuración de agente simplemente pidiéndole a OpenClaw/Hermes Agent que lo haga. Así es como las habilidades y capacidades que escribí para mi OpenClaw/Hermes Agent se pueden agregar automáticamente a TU OpenClaw, incluida la salida completa de skillify de 10 pasos, empaquetada para que puedas colocarla en tu OpenClaw/Hermes Agent y funcione de inmediato.
La lista de verificación de skillify anterior no es una sugerencia. Es lo que gbrain doctor realmente verifica.*
gbrain doctor --fix auto-repara violaciones DRY, reemplaza bloques duplicados con referencias de convención, todo protegido por comprobaciones del árbol de trabajo de git para que nada se sobrescriba.
Por qué Hermes Agent no es suficiente por sí solo
Hermes Agent de Nous Research hace algo genuinamente genial: tiene una herramienta skill_manage que permite al agente mismo crear, parchear y eliminar habilidades basándose en lo que aprende. Cuando el agente termina una tarea compleja o se recupera de un error, propone una habilidad y la escribe en el disco. Esa es memoria procedimental que el agente gana por sí mismo. Divulgación progresiva (carga un índice de habilidades primero, extrae el SKILL.md completo solo cuando se selecciona). Memoria limitada (MEMORY.md limitado a 2,200 caracteres). Activación condicional (las habilidades se ocultan automáticamente cuando las herramientas requeridas no están disponibles). Diseño inteligente.
Pero Hermes no prueba sus habilidades. No hay pruebas unitarias en el código determinista. No hay evaluaciones de resolución para verificar el enrutamiento. No hay check-resolvable para encontrar habilidades ocultas. No hay auditoría DRY para detectar duplicados. No hay verificación de salud diaria que se ponga roja cuando algo se desvía.
Los modos de fallo que he visto acumularse en cualquier sistema de habilidades no probado:
- El agente crea deploy-k8s el lunes. El jueves crea kubernetes-deploy desde una conversación diferente. Ambos existen. Ambos se activan con frases similares. Enrutamiento ambiguo, y nadie se da cuenta hasta que el incorrecto se activa en el momento equivocado.
- La habilidad funciona perfectamente cuando se escribe. Seis semanas después, la API upstream cambia de forma. La habilidad devuelve silenciosamente basura hasta que un humano lo nota.
- Una habilidad creada autónomamente tiene un disparador débil que nunca coincide. Se convierte en huérfana, consumiendo tokens de índice, nunca ejecutándose, pudriéndose lentamente.
Este es el problema de "sin pruebas, cualquier código se pudre" que la ingeniería de software resolvió en 2005. Las habilidades de los agentes no son diferentes. Hermes maneja la creación hermosamente. GBrain maneja la verificación. Necesitas ambos.
La gran idea
En un equipo de ingeniería de software saludable, cada error recibe una prueba. Esa prueba vive para siempre. El error se vuelve estructuralmente imposible de repetir. Los agentes de IA deberían funcionar de la misma manera.
Cada error se convierte en una habilidad. Cada habilidad tiene evaluaciones. Cada evaluación se ejecuta diariamente. El juicio del agente mejora permanentemente, no solo para la sesión actual, no solo mientras la ventana de contexto lo permita.
El error del viaje no volverá a ocurrir. El error de la zona horaria no volverá a ocurrir. Y cuando aparezca el próximo error (y lo hará, porque esto es un juego adversarial contra la entropía y el gusto), también se le aplicará skillify.
El agente con el que trabaje dentro de un año estará moldeado por cada error que cometió en el año anterior. Eso no es un lujo. Es toda la tesis.
Hierve el océano. Haz que tu agente haga algo, luego aplícale skillify. Hazlo todos los días y tendrás un maldito OpenClaw inteligente que hace todo lo que quieres que haga.
O simplemente puedes cargar GBrain, usar todo el código que ya he escrito y saltar directamente a tu propio Jarvis de Iron Man.
--
GStack para acelerar en Claude Code github.com/garrytan/gstack
GBrain para construir tu propio Jarvis de Iron Man en OpenClaw/Hermes Agent github.com/garrytan/gbrain
