unlazy: el método Depth Tree para agentes de código

Qué hace la skill unlazy

La skill unlazy está diseñada para evitar un fallo concreto: que un agente de programación informe de que el trabajo está terminado antes de terminarlo. Su elemento central es el árbol de profundidad (Depth Tree), un método que divide una tarea en capas y considera que sólo la capa inferior es trabajo real. La versión 2 trasladó la aplicación de las comprobaciones de la prosa a los archivos. Así, el agente debe demostrar que ha terminado ejecutando una lista de comandos, en lugar de limitarse a afirmarlo.

Leonxlnx publica esta skill en github.com/Leonxlnx/unlazy con licencia MIT. Esta guía se basa en la versión 2.0.0, publicada el 2026-08-10. Las skills de este ámbito cambian rápidamente. Lea el CHANGELOG del repositorio antes de copiar cualquiera de estos elementos en una configuración que vaya a mantener en ejecución.

Aquí, una skill significa lo habitual: un archivo SKILL.md que el harness carga en el contexto del modelo cuando la tarea coincide con su descripción. Si este mecanismo es nuevo para usted, empiece por qué es una skill de agente y cómo un harness carga una. unlazy es markdown sin formato junto con algunos scripts de Node. No necesita un servidor ni su propia clave de API.

Por qué los agentes se detienen en el 80 % y omiten la tercera instrucción

Este comportamiento sigue un patrón reconocible. Pide cuatro cosas. La respuesta cubre la primera, la segunda y la cuarta. El resumen final marca las cuatro como completadas. No se produce ningún error, por lo que nada lo señala, y descubre la omisión una semana después.

El README de unlazy relaciona este problema con trabajos publicados sobre la falta de diligencia de los modelos y cita la «truncación prematura de respuestas y el cumplimiento parcial de solicitudes con varias partes» (la cita corresponde a arXiv 2512.20662). El mismo README expone claramente la premisa de diseño: la prosa no puede imponer el cumplimiento de la prosa. Pedirle a un agente que se esfuerce más es añadir más prosa al mismo contexto que produjo la omisión.

Por eso la versión 2 mantiene su estado en archivos. Una casilla en GATES.md queda fuera del control discrecional del modelo. La casilla tiene una línea de evidencia debajo o no la tiene, y un script puede indicarle cuál de las dos situaciones se cumple sin preguntárselo al agente.

El árbol de profundidad, capa por capa

El árbol de profundidad es una descomposición con una regla sobre dónde se permite realizar el trabajo. La referencia del método indica:

Divida en puntos de unión naturales; use una estructura binaria cuando esos puntos lo permitan, con N capas de profundidad.

Las hojas son los únicos lugares donde se realiza trabajo real; todas las capas superiores se dedican a la descomposición y la integración.

Una hoja es más grande que un punto de una lista. La referencia establece un tamaño mínimo:

Una hoja es una unidad de trabajo real. Requiere diez minutos o más de trabajo concentrado, produce un entregable coherente y tiene un único archivo de control.

Ese límite evita que un árbol profundo se convierta en trabajo improductivo. Si una hoja dice «cambiar el nombre de la variable», no supera la prueba y la división anterior avanzó una capa de más.

Cada hoja pasa entonces por cuatro fases: implementarla por completo y sin marcadores de posición, volver a leerla como lo haría un experto del dominio, buscar defectos y pulirla cuando hacerlo no suponga un coste adicional. Las fases son también la razón por la que una hoja necesita un tamaño mínimo. Aplicar cuatro fases a un cambio de dos minutos es puro teatro.

Elija la profundidad al invocar la skill:

/unlazy tree 5 refactor the payment module

También puede usar lenguaje natural, porque la descripción de la skill busca la intención y no un comando con barra:

tree 3 build the landing page and do not stop until every gate is checked

La referencia define intervalos de profundidad. tree 2 o tree 3 corresponde a una funcionalidad, una búsqueda de errores o un documento, trabajado en solitario durante una sesión y distribuido entre 2 y 4 hojas. tree 4 o tree 5 corresponde a un subsistema, una refactorización o una revisión importante, donde 8 a 16 hojas es «más de lo que un contexto puede manejar bien». tree 6 o tree 7 corresponde a un proyecto completo, ejecutado en modo orquestado y con las hojas asignadas a unidades de trabajo independientes.

Si no especifica una profundidad, la skill recibe la instrucción de «elegir el N más pequeño cuyas hojas coincidan con las partes naturales de la tarea» y la indicación explícita de no profundizar una capa más de forma predeterminada. La profundidad describe el trabajo, por lo que aumentar el número no mejora la calidad.

Cómo es un archivo de gates

Antes de iniciar cualquier trabajo, el agente escribe los criterios de aceptación en un archivo de gates. Cada gate es una casilla de verificación con un comando debajo.

# Gates: pricing section

- [ ] G1: three tiers render with real copy
  CHECK: node check.js pricing --tiers
  EXPECT: 3/3 tiers ok
  EVIDENCE: pending

- [ ] G2: annual toggle changes both price and label
  CHECK: node check.js pricing --toggle
  EXPECT: toggle ok
  EVIDENCE: pending

CHECK es el comando. EXPECT es la salida que cuenta como válida. EVIDENCE comienza en pending y debe sustituirse por lo que el comando haya mostrado realmente. La skill incluye scripts/gate-check.mjs para analizar esos archivos e informar de qué gates siguen abiertos. Así puede auditar una ejecución sin leer la transcripción.

La filosofía se resume en una línea, y SKILL.md la escribe en una sola línea:

Un informe es un conjunto de afirmaciones respaldadas por un registro, nunca una impresión de que el trabajo ha terminado.

La regla que se deriva es «no generar el informe hasta completar el registro». También exige que cada número del resumen final se vuelva a medir al generar el informe o se marque como no verificado. Un gate no puede cerrarse porque el agente considere que ha terminado. Se cierra pegando una salida que coincide con EXPECT o que no coincide.

Escriba gates que otra persona pueda ejecutar. «Parece correcto» no es una comprobación. test -s dist/index.html && echo ok que muestre ok sí es una comprobación, porque falla claramente cuando el archivo está vacío o no existe.

El contrato de PLAN.md, antes de cualquier trabajo en paralelo

Cuando un árbol tiene suficiente amplitud para que las hojas se ejecuten en contextos independientes, esas hojas dejan de compartir supuestos. La referencia del método coloca un contrato antes de la ramificación:

Los contratos van antes de la ramificación. Las interfaces, la propiedad de los datos, las convenciones de nombres y las convenciones de errores deben estar en PLAN.md antes de que se inicie cualquier hoja.

La razón es concreta. Dos subagentes a los que se les indique «añadir gestión de errores» inventarán dos estructuras de error diferentes, y ambas hojas superarán sus propias comprobaciones porque cada una es correcta de forma local. El fallo sólo aparece cuando se integran. Las comprobaciones de rama existen para ese momento: las comprobaciones de una rama demuestran que «los hijos se han fusionado, las interfaces coinciden, el comportamiento de extremo a extremo funciona y no hay regresiones en los hermanos».

En el modo orquestado, el controlador entrega a cada subagente la sección del contrato de PLAN.md, no el archivo completo ni el historial propio del controlador, además del archivo de comprobaciones de esa hoja sin modificaciones. Cuando el subagente termina, el controlador vuelve a ejecutar las comprobaciones por su cuenta. Si un subagente «marcó sus propias casillas sin pruebas», se le devuelve la tarea con las comprobaciones específicas que no se han cumplido.

La orquestación tiene un umbral mínimo. Por debajo de aproximadamente media hora de trabajo real, la referencia indica que se debe trabajar en solitario, porque cada subagente tiene que reconstruir desde cero su comprensión de la tarea y ese trabajo de preparación cuesta más que la atención adicional que aporta.

¿Cómo se instala la skill unlazy?

La vía compatible es la CLI de skills:

npx skills add Leonxlnx/unlazy

La instalación manual consiste en clonar el repositorio en el directorio de skills del agente:

git clone https://github.com/Leonxlnx/unlazy ~/.claude/skills/unlazy

git clone https://github.com/Leonxlnx/unlazy ~/.codex/skills/unlazy

Después, compruebe que se haya instalado:

ls ~/.claude/skills/unlazy/SKILL.md

La ruta que se muestra indica que el archivo está en el disco. No such file or directory significa que el clon se creó en otra ubicación, normalmente porque el directorio de skills no existía con el nombre que suponía y git creó uno nuevo. Tampoco confíe sólo en lo que indique el agente. El aviso de instalación del propio README termina con la misma advertencia: "No diga que está instalado hasta haber verificado que el archivo está realmente en el disco."

En un harness sin cargador de skills, pegue el contenido de SKILL.md en el prompt del sistema o en el archivo de reglas. Esta es la alternativa documentada. Por eso el método funciona en Claude Code, Codex, Cursor y cualquier otra herramienta que lea un archivo de instrucciones Markdown simple. Si quiere saber qué hace que un SKILL.md se cargue de forma fiable, cómo escribir su propia skill de agente explica el frontmatter y la coincidencia de la descripción que determinan si se activa.

¿Funciona el hook Stop fuera de Claude Code?

No. Esta es la parte que debe quedar clara. Todo lo anterior son instrucciones, y las instrucciones se pueden ignorar. El único mecanismo de cumplimiento estructural es un hook Stop, y los hooks Stop son una función de Claude Code.

node <path-to-skill>/scripts/install-hooks.mjs            # this project only (settings.local.json)
node <path-to-skill>/scripts/install-hooks.mjs --global   # every project
node <path-to-skill>/scripts/install-hooks.mjs --uninstall

Un hook Stop se ejecuta cuando el agente intenta finalizar su turno. Este hook analiza los archivos de gates y bloquea la finalización mientras haya gates sin cumplir. Así, el turno no puede terminar con una casilla sin comprobar. Lee archivos y no realiza llamadas al modelo. Por eso el README indica que consume cero tokens. Para conocer el mecanismo general y los demás eventos a los que puede asociarse, consulte cómo se ejecutan los hooks de Claude Code durante un turno.

Tiene una vía de escape, que es más importante de lo que parece. Si el agente no logra avanzar en ningún gate durante seis intentos consecutivos de finalización bloqueada, el hook le permite continuar con una advertencia en lugar de dejarlo atrapado. Una línea ABANDON: <gate> <reason> siempre se respeta como salida explícita. Sin esas dos vías de escape, un gate imposible en su entorno consumiría tokens hasta que tuviera que finalizar la sesión manualmente.

En Codex, Cursor o cualquier otro harness, install-hooks.mjs no tiene ningún lugar donde instalarse. Seguirá teniendo el archivo de gates y las comprobaciones ejecutables, pero no habrá ningún mecanismo estructural que impida al modelo finalizar el turno antes de tiempo. En esos entornos, el archivo de gates es un documento que debe leer.

unlazy o ponytail: ¿cuál necesitas?

Estas dos habilidades fueron tendencia durante la misma temporada y tiran en direcciones opuestas en cuanto al volumen de trabajo, por lo que es fácil confundirlas.

ponytail hace que el agente se comporte como un desarrollador sénior cuya primera pregunta es si el código debe existir. Reduce el alcance, prefiere la biblioteca estándar y minimiza el diff. unlazy da por acordado el alcance y aumenta el esfuerzo hasta que cada parte queda terminada y comprobada.

Por tanto, elige según el fallo que estés observando. Si tu agente convierte una función pequeña en un framework, necesitas la habilidad ponytail y su personalidad de desarrollador sénior que evita trabajo innecesario. Si tu agente deja sin hacer el tercer elemento de una solicitud de cuatro partes y después informa de que ha terminado correctamente, necesitas unlazy.

Es posible ejecutar ambas, y el orden importa. Define primero el alcance con la pregunta de ponytail y después entrega ese alcance acordado a las comprobaciones de unlazy. Si lo haces al revés, construirás un árbol de hojas para trabajo que ponytail habría eliminado y aplicarás el multiplicador de profundidad a todo ese trabajo. Este orden es mi recomendación, no una integración documentada entre ambos proyectos.

¿Cuál es el coste de la profundidad en un agente alojado en un VPS?

La profundidad multiplica el esfuerzo, y el esfuerzo se mide en tokens. En un VPS donde un agente usa tu propia clave de API, ese multiplicador se convierte en dinero.

[
  {
    "label": "Skill run vs no skill, output tokens",
    "low_multiplier": 1.6,
    "high_multiplier": 3.9
  },
  {
    "label": "tree 6 vs tree 3, total cost",
    "low_multiplier": 1.0,
    "high_multiplier": 1.5
  }
]

Esas son las cifras de los autores obtenidas en su propia prueba, con fecha de 2026-08-10. No las hemos reproducido, así que deben interpretarse como una tendencia y no como una previsión. La disciplina en modo solo elevó la salida hasta aproximadamente 1.6 a 3.9 veces la línea base, mientras que pasar del árbol 3 al árbol 6 dentro de un mismo contexto sólo añadió entre 1.0 y 1.5 veces, muy por debajo de las ocho veces que cabría esperar de tres divisiones binarias adicionales.

Una mayor profundidad no es proporcionalmente más cara porque redistribuye el esfuerzo en lugar de añadir contextos. La referencia sobre la economía de tokens es clara sobre dónde está el multiplicador real: «Lo que multiplica el coste es la orquestación, y debe multiplicarlo, porque cada hoja obtiene un contexto nuevo». El modo solo multiplica los tokens de salida dentro de un contexto. El modo orquestado multiplica los contextos, y cada contexto nuevo vuelve a leer el contrato y su archivo de condiciones antes de hacer algo útil.

Hay un segundo coste que es fácil pasar por alto, y la misma referencia lo menciona. En su prueba, una ejecución monolítica y profunda «consumió aproximadamente 58 millones de tokens de entrada en caché» porque un único contexto en constante crecimiento conservó todo. La entrada en caché es más barata por token, pero con ese volumen también aparece en la factura.

De aquí se derivan cuatro ajustes:

• Elige la profundidad mínima cuyas hojas sean unidades de trabajo reales y detente ahí. La profundidad que no necesitas es gasto que no necesitas.
• Mantente en modo solo cuando el trabajo dure menos de media hora, porque la configuración de subagentes cuesta más de lo que devuelve el contexto nuevo.
• Instala el hook Stop si usas Claude Code. Es la única parte de todo esto que se ejecuta de forma gratuita.
• Establece un límite máximo de gasto a nivel de cuenta antes de iniciar cualquier tarea larga.

Este último punto es el más importante. Una skill diseñada para no detenerse pronto es, por diseño, una skill que sigue trabajando. Los presupuestos y las alertas son una tarea independiente del prompting, y mantener bajo control el coste de un agente en un VPS explica los límites que conviene configurar primero.

Qué midieron los autores y qué demuestra

El repositorio publica su propia prueba, algo menos habitual de lo que debería. Su configuración, citada del README, fue la siguiente: "dos tareas de construcción desde cero (un sitio de marketing y un sistema solar en three.js), tres condiciones para cada una (sin skill, tree 3, tree 6), una carpeta nueva y una sesión nueva por ejecución, el mismo modelo y el mismo cuerpo de la solicitud. Agentes independientes revisaron el código de cada resultado, lo volvieron a verificar de forma adversarial y lo probaron en directo en un navegador."

[
  {
    "label": "Self-found defects fixed, skill runs",
    "low_count": 4,
    "high_count": 10
  },
  {
    "label": "Wrong numbers in report, skill runs",
    "low_count": 1,
    "high_count": 3
  },
  {
    "label": "Wrong numbers in report, baseline runs",
    "low_count": 0,
    "high_count": 0
  }
]

Lea dos veces la fila central. En la propia prueba de los autores, el skill ejecuta entre 4 y 10 correcciones que el agente detectó por sí mismo antes de entregar el resultado, y cada ejecución del skill publicó después un informe final con entre 1 y 3 cifras incorrectas, frente a 0 en las ejecuciones de referencia. Más trabajo produjo mejores compilaciones y peores resúmenes. Ese es el hallazgo que sustenta la regla del registro y la instrucción de volver a medir cada cifra al redactar el informe o marcarla como no verificada.

También conviene conservar otro resultado: "El único fallo grave en directo fue una compilación de referencia, y su informe afirmaba que el caso se había resuelto." Un resumen seguro de sí mismo sobre una compilación rota es exactamente lo que pretenden evitar las barreras.

Ahora, las limitaciones. Fueron seis ejecuciones, dos tareas de compilación y un modelo, ejecutadas y documentadas por el propio autor del skill. Esto no constituye una replicación independiente, y lo citamos como una afirmación de los autores con fecha de 2026-08-10. Pruébelo en su propio trabajo: ejecute la misma tarea dos veces, una sin cambios y otra con un archivo de barreras, y después cuente las barreras que se cerraron con pruebas que usted pueda volver a ejecutar. Ese recuento es la única cifra de este ámbito que le pertenece.

FAQ

¿Qué es el árbol de profundidad de la skill unlazy?

Es un método de descomposición. Una tarea se divide en puntos naturales a lo largo de N capas, y sólo las hojas del nivel inferior cuentan como trabajo. La skill define una hoja como al menos diez minutos de trabajo concentrado, con un entregable coherente y un archivo de gates. Si una hoja se puede terminar en dos minutos, la división bajó una capa de más. Todas las capas superiores a las hojas corresponden a descomposición e integración. Cada rama tiene sus propios gates, que demuestran que los elementos secundarios se fusionaron y que las interfaces coinciden. La profundidad se elige al invocar la skill, por ejemplo tree 5. El valor predeterminado documentado es la menor profundidad cuyas hojas sean unidades de trabajo reales.

¿Funciona la skill unlazy fuera de Claude Code?

En parte. La skill está escrita en markdown, por lo que Codex, Cursor y cualquier herramienta que lea un SKILL.md o un prompt del sistema pueden usar el árbol de profundidad, el archivo de gates, las comprobaciones ejecutables y las cuatro pasadas por hoja. La aplicación estricta es diferente. El hook Stop, que bloquea el final de un turno mientras no se cumplan los gates, es una función de Claude Code y se instala con node <path-to-skill>/scripts/install-hooks.mjs. En otros entornos, nada impide estructuralmente que el modelo termine el turno antes de tiempo. Por tanto, usted debe leer el archivo de gates y enviárselo de nuevo.

¿Cuánto añade la skill unlazy a mi consumo de tokens?

Los autores informan de entre 1.6 y 3.9 veces los tokens de salida de una ejecución sin skill en modo individual, además de unos cientos de tokens de sobrecarga del propio archivo de gates. Aumentar la profundidad dentro de un mismo contexto es casi gratuito en comparación: entre 1.0 y 1.5 veces al pasar del árbol 3 al árbol 6. El modo orquestado es el más costoso, porque cada hoja requiere un contexto nuevo que vuelve a leer el contrato y sus gates antes de trabajar. El hook Stop no añade nada, porque sólo analiza archivos. Estas son las cifras de los autores a fecha de 2026-08-10, no mediciones que hayamos repetido.

¿Debo usar unlazy o ponytail?

Adapte la skill al fallo que tenga delante. ponytail está pensada para un agente que escribe demasiado: simula a un desarrollador sénior que pregunta si el código debe existir y recurre primero a la biblioteca estándar. unlazy está pensada para un agente que termina una parte demasiado pequeña de lo solicitado: obliga a descomponer el trabajo y no permite cerrar un gate sin pruebas. Si quiere usar ambas, defina primero el alcance con ponytail y después entrégueselo a unlazy. Así no aplicará un multiplicador de esfuerzo a trabajo que debería haberse eliminado.

¿Por qué mi agente sigue deteniéndose antes de tiempo después de instalar unlazy?

Compruebe cuatro aspectos. Primero, confirme que la skill está en disco con ls ~/.claude/skills/unlazy/SKILL.md, porque el error más habitual es clonar en un directorio que no existía. Segundo, confirme que se escribió un archivo de gates antes de comenzar el trabajo, porque el hook analiza los archivos de gates y un GATES.md ausente no le deja nada que bloquear. Tercero, confirme dónde se instaló el hook: la ejecución simple de install-hooks.mjs sólo escribe en el settings.local.json de este proyecto, por lo que otro proyecto necesita --global. Cuarto, recuerde que el mecanismo de salida funciona según lo previsto: seis detenciones bloqueadas consecutivas sin progreso en los gates permiten que el agente continúe con una advertencia, y una línea ABANDON: <gate> <reason> termina el intento intencionadamente.