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 trayectorias, 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 merece.
Pero las piezas no son una práctica.
LangChain te da herramientas de prueba. Nunca te dice qué probar, en qué orden, o cuándo has terminado.
No hay un flujo de trabajo definido que diga, en orden:
- ocurrió este fallo
- ahora escribe una habilidad
- ahora escribe el código determinista
- ahora escribe pruebas unitarias
- ahora escribe evaluaciones LLM
- ahora añade un disparador de resolución
- ahora evalúa el resolvedor
- ahora audita duplicados
- ahora 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ía de la "fiabilidad" de los agentes de IA se basa en sensaciones. Ajustes de prompt. Mensajes de sistema más grandes. Invocaciones 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 ayudas para pruebas unitarias y dijeron "buena suerte".
Mi agente cometió errores dos veces esta semana. Ninguno de los dos fallos puede volver a ocurrir. No porque lo pedí amablemente. Porque convertí cada fallo en una solución estructural permanente: una habilidad con pruebas que se ejecutan todos los días, para siempre.
Yo llamo a esta práctica "skillify". Una vez que la usas, tus agentes no seguirán cometiendo los mismos errores. Así es como funciona.
Fallo 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 de calendario en vivo → bloqueado (demasiado atrás).
- Intentó búsqueda en correo electrónico → resultados ruidosos, nada concluyente.
- Intentó la API de 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 de 2013 a 2026. Ya indexados. Ya locales. A un grep de distancia.
El agente simplemente no miró allí primero.
En el framework sobre el que he estado escribiendo (thin harness, fat skills) hay una distinción clave entre el trabajo que requiere juicio y el trabajo que requiere precisión. Yo los llamo latente y determinista. El grep de calendario es determinista. Misma entrada, misma salida, cada vez. 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 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 dependiendo de lo que pases.
Aquí está la habilidad que surgió de este fallo:
nombre: calendar-recall descripción: "Búsqueda de calendario histórico con prioridad cerebral. USA SIEMPRE esto antes de cualquier API en vivo para cualquier evento que no sea futuro o de las últimas 48 horas."
Y la regla estricta dentro:
Las API de calendario en vivo son SOLO para eventos en el FUTURO o las ÚLTIMAS 48 HORAS. Todo lo histórico pasa primero por la base de conocimiento local.
Aquí está lo que hace que esto funcione: el propio agente 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 "Singapur"
Encontrado(s) 2 día(s) coincidente(s): ── 2016-05-07 ── Vuelo a Singapur, check-in en Mandarin Oriental ── 2016-05-08 ── Almuerzo con inversores en Fullerton Hotel
Código que se ejecuta en menos de 100 milisegundos (la mayor parte es el inicio de Bun; el grep real es de menos de 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 fallo anterior se vuelve estructuralmente inalcanzable. La habilidad dice "busca local primero". El script hace la búsqueda. El agente nunca tiene la oportunidad de ser inteligente al respecto o volver a equivocarse.
Fallo 2: "28 minutos" (Pasos 1 + 2 nuevamente)
Mismo día. El agente dice: "Tu próxima reunión es en 28 minutos."
Realidad: 88 minutos después. El agente había hecho la conversión de zona horaria UTC→PT mentalmente y se equivocó por exactamente una hora.
La cuestión es que ya existía un script (context-now.mjs) que genera esto:
{ "ahora": "2026-04-21T07:38:12-07:00", "proximosEventos": [{ "resumen": "App Ops Sprint Planning", "minutosHasta": 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) hecho en espacio latente. El modelo estaba haciendo cálculos mentales cuando un script tenía la respuesta.
La solución: context-now, la habilidad:
nombre: context-now descripción: "Disciplina SIEMPRE ACTIVA: ejecuta context-now.mjs antes de hacer CUALQUIER afirmación sensible al tiempo. Nunca hagas la conversión UTC→PT en tu cabeza."
Aquí está el simple antes/después con y sin estas habilidades simples:
Skillify: El patrón que te salvará la cordura
Dos fallos. Misma forma. El agente tenía la herramienta correcta y eligió la inteligencia 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 evita que se repita.
Skillify es la solución. Cada fallo 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 fallo es promovido:
□ 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 del resolvedor — verificar que el disparador realmente enruta □ 8. Auditoría de resolubilidad + DRY □ 9. Prueba de humo E2E □ 10. Reglas de archivo cerebral
Una característica que no pasa los diez no es una habilidad. Es solo código que funciona hoy.
Los dos fallos anteriores ya recorrieron los pasos 1 y 2: escribe el SKILL.md (el contrato), luego escribe 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 fallo. Se convirtió en un verbo.
Skillify como verbo
Para mí, construyendo mi OpenClaw (y GBrain), la lista de verificación comenzó como un protocolo de respuesta a fallos. Luego se convirtió en la forma en que construí todo.
Así es como se ve mi flujo de trabajo real. Estoy hablando con mi agente en lenguaje natural. Construimos algo juntos en conversación. Lo pruebo. Funciona. Luego digo una palabra:
Garry:
¡carajo, funcionó! ¿puedes recordar esto como una habilidad de webhook y skillifícalo, la próxima vez que necesitemos hacer algunos webhooks? ¿por qué fue tan difícil hacerlo bien? de todos modos, ahora está bien. también hazlo DRY
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 de 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.
Otra. 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, deberíamos pedirle al usuario que ejecute gstack browser y nos dé un código de par de agente. ¡skillifícalo!
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 enruta a la herramienta correcta automáticamente.
O esto. Noté que el agente seguía enviándome enlaces de ngrok sin verificar si realmente funcionaban:
Garry:
¿podemos hacer una habilidad que diga que cada vez que me envíes un enlace, tengas que hacerle un curl tú mismo para asegurarte de que el endpoint esté abierto y el túnel funcione? ¡skillifícalo!
O la doble reserva de 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. Haz una habilidad, hazla determinista para verificar este tipo de cosas.
Una oración. Código, habilidad, pruebas, entrada de resolvedor, auditoría de alcanzabilidad. Toda la lista de verificación 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 "permanente" significa: SKILL.md, código determinista, pruebas unitarias, pruebas de integración, evaluaciones LLM, disparador de resolución, evaluación de resolvedor, auditoría DRY, prueba de humo, archivo cerebral. 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, aserciones 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 descarta silenciosamente eventos con caracteres Unicode en el campo de ubicación. dateFromPath devuelve null para fechas de año bisiesto. formatJson omite el array de asistentes cuando solo hay una persona. Pequeño, aburrido, crítico. Si el script produce una salida incorrecta, la habilidad produce respuestas incorrectas, y el agente me dice con confianza lo incorrecto.
Para context-now, las pruebas unitarias verifican el formato de zona horaria, la detección de horas de silencio y el cálculo de minutosHasta a través de los límites de horario de verano. Una prueba introduce un tiempo 3 minutos antes de una transición de horario de verano y verifica que la salida no salte 60 minutos. Ese es exactamente el error que causó el fallo 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 finales de línea de Windows, eventos que cruzan 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 evaluar. "¿Es útil este resumen de calendario?" 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 diariamente. Una de ellas le da al agente un mensaje como "oye, mi vuelo sale en unos 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 él mismo, la evaluación falla.
Otra evaluación le da al agente una marca de tiempo UTC y 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 cuando dijiste "¡mierda!" o "qué carajo". Esos son los casos de prueba que te faltan.
Paso 6: Disparador de resolución
Un resolvedor 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 del resolvedor
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 enrutar a esta habilidad". Una evaluación del resolvedor prueba que realmente lo hace.
Mi suite de evaluación del resolvedor tiene más de 50 casos de prueba como este:
{ intención: 'revisa mis firmas', habilidadEsperada: 'asistente-ejecutivo' }, { intención: 'quién es Pedro Franceschi', habilidadEsperada: 'operaciones-cerebrales' }, { intención: 'guarda este artículo', habilidadEsperada: 'ingesta-ideas' }, { intención: 'a qué hora es mi reunión', habilidadEsperada: 'contexto-ahora' }, { intención: 'encuentra mi viaje de 2016', habilidadEsperada: 'recuperacion-calendario' },
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: la habilidad incorrecta se activa, porque dos disparadores se superponen. "Qué hay en mi calendario mañana" debería enrutar a verificación-calendario, no a recuperacion-calendario ni a google-calendario. Tres habilidades, tres dominios de tiempo diferentes, una frase que podría coincidir plausiblemente con cualquiera de ellos. La evaluación del resolvedor detecta la ambigüedad antes de que un usuario la encuentre.
Ejecuto estas evaluaciones tanto como pruebas estructurales deterministas (¿la tabla 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 nacían pero no se registraban.
Así que construí check-resolvable. Una meta-prueba que recorre toda la cadena: resolvedor 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 oscuras.
- 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 referenciado por una habilidad es realmente invocable (el archivo existe, exporta las funciones correctas).
- Ninguna dos habilidades tienen descripciones de disparador superpuestas que causarían enrutamiento ambiguo.
La auditoría DRY se ejecuta junto con él. Terminas con quince habilidades que más o menos hacen lo mismo si no tienes cuidado, y el resolvedor elige la que sea. Para recuperacion-calendario:
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 pisa el carril de otra y la auditoría falla 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 ignorar todo y improvisar. La prueba de humo detecta eso.
Paso 10: Reglas de archivo cerebral
Cada habilidad que escribe en la base de conocimiento necesita saber dónde van las cosas. Una persona va en personas/. Una empresa va en empresas/. Un análisis de políticas va en civico/. Detecté 10 de 13 habilidades de escritura cerebral 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 de mi GBrain Skill Pack
El patrón skillify no es específico de OpenClaw o de ningún arnés en particular. Está integrado en GBrain. GBrain es el motor de conocimiento de código abierto que escribí y que se encuentra debajo de cualquier arnés que uses. Gestiona tu repositorio cerebral, ejecuta tus evaluaciones y aplica las puertas 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 pueden agregarse automáticamente a TU OpenClaw, incluida toda la salida de skillify de 10 pasos, empaquetada para que puedas colocarla en tu OpenClaw/Hermes Agent y simplemente funcione.
La lista de verificación de skillify de antes no es una sugerencia. Es lo que gbrain doctor realmente verifica.*
gbrain doctor --fix repara automáticamente 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 propio agente 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. Sin pruebas unitarias en el código determinista. Sin evaluaciones de resolvedor para verificar el enrutamiento. Sin check-resolvable para encontrar habilidades oscuras. Sin auditoría DRY para detectar duplicados. Sin 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 ascendente cambia de forma. La habilidad devuelve silenciosamente basura hasta que un humano la detecta.
- Una habilidad creada autónomamente tiene un disparador débil que nunca coincide. Se convierte en un huérfano, consumiendo tokens de índice, nunca ejecutándose, pudriéndose lentamente.
Este es el problema de "sin pruebas, cualquier base de código se pudre" que la ingeniería de software resolvió en 2005. Las habilidades de agente no son diferentes. Hermes maneja la creación de manera hermosa. GBrain maneja la verificación. Necesitas ambos.
La gran idea
En un equipo de ingeniería de software saludable, cada error tiene 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 fallo 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 se mantenga.
El fallo del viaje no volverá a ocurrir. El fallo de la zona horaria no volverá a ocurrir. Y cuando aparezca el próximo fallo (y lo hará, porque esto es un juego adversarial contra la entropía y el gusto), también será skillificado.
El agente con el que trabajo dentro de un año estará moldeado por cada error que cometió en el año anterior. Eso no es algo agradable de tener. Es toda la tesis.
Hierve el océano. Haz que tu agente haga algo, luego skillifícalo. Haces eso todos los días y tienes un maldito OpenClaw inteligente que hace todo lo que quieres que haga.
O podrías simplemente cargar GBrain, usar todo el código que ya he escrito, y saltar directamente a tu propio Jarvis de Iron Man más pronto.
--
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
