unlazy: Depth Tree para que un agente no termine antes

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 Depth Tree, un método que divide una tarea según sus límites reales y asigna a cada hoja sus propios criterios de aceptación. La versión 2 trasladó la verificación desde la prosa a los archivos, de modo que el agente debe demostrar que ha terminado mediante una lista de comandos ejecutables, en lugar de limitarse a afirmarlo.

Leonxlnx publica esta skill en github.com/Leonxlnx/unlazy con licencia MIT. No hay ninguna versión etiquetada que fijar: a fecha de 2026-10-11, las listas de tags y releases del repositorio están vacías. Esta guía se escribió originalmente a partir del hito de código fuente 2.0.0, fechado el 2026-08-10. El 2026-10-11 volvimos a comprobarla con el código fuente actual de main. El CHANGELOG identifica ese código como "Unreleased, target 2.1.0" e indica que no declara ningún Git tag ni GitHub Release para 2.1.0. Si ejecuta hoy el comando de instalación, obtendrá ese código fuente más reciente, no 2.0.0. Las skills de este ámbito cambian rápidamente, así que lea el CHANGELOG del repositorio antes de copiar cualquiera de estas instrucciones en una configuración que vaya a dejar 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 la carga un harness. unlazy es markdown sencillo junto con algunos scripts de Node, por lo que no necesita un servidor ni su propia API key.

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

Este comportamiento tiene una forma reconocible. Pide cuatro cosas. La respuesta cubre la primera, la segunda y la cuarta. El resumen final indica que las cuatro se completaron. No se produjo ningún error, por lo que nada lo señaló, y descubre la omisión una semana después.

El README de unlazy relaciona este problema con trabajos publicados sobre la pereza de los modelos. Cita arXiv 2512.20662 por la conclusión de que «Los prompts detallados de varias partes siguen presentando cumplimiento parcial y truncamiento prematuro en los modelos probados». El estado de las compuertas expone claramente la premisa de diseño: «Las reglas anteriores están redactadas en prosa, y la prosa es la capa que este proyecto ya considera más débil». Indicar a un agente que lo intente con más esfuerzo añade más prosa al mismo contexto que produjo la deficiencia.

Por eso la versión 2 mantiene su estado en archivos. Una casilla de verificación en GATES.md queda fuera de la discreción del modelo. La compuerta tiene evidencia asociada o no la tiene, y un script puede indicarle cuál es la situación sin preguntar al agente.

El árbol de profundidad, capa por capa

El árbol de profundidad es una descomposición con una regla sobre dónde pueden situarse las divisiones. La referencia del método indica:

Divida sólo en límites reales de dominio, componentes o verificación. Las divisiones binarias son opcionales.

Haga que la capa 1 sea la tarea solicitada.

Las hojas contienen los entregables. Cada capa superior integra y verifica lo que devuelven sus elementos secundarios.

Una hoja es más que un punto de una lista. La referencia la dimensiona según el resultado, no según el tiempo empleado:

Haga que cada hoja sea un entregable coherente.

Combine las hojas adyacentes pequeñas; divida una hoja que oculte varios resultados independientes.

Esta regla evita que un árbol profundo se convierta en trabajo improductivo. Si una hoja dice «cambie el nombre de la variable», no supera la prueba y la división anterior descendió una capa de más.

A continuación, cada hoja ejecuta cuatro pasadas: impleméntela por completo sin marcadores de posición, vuelva a leerla como lo haría un experto del dominio, busque defectos y aplique mejoras de acabado cuando sean económicas. Repita el proceso hasta que una pasada completa de mejora no encuentre nada. Estas pasadas son otra razón para combinar las hojas pequeñas. Cuatro pasadas sobre un cambio de dos minutos son sólo una formalidad.

Elija la profundidad al invocar la capacidad:

/unlazy tree 5 refactor the payment module

También puede usar lenguaje sencillo, porque la descripción de la capacidad identifica la intención y no un comando con barra:

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

Las versiones anteriores de esta guía citaban intervalos de profundidad con un número de hojas para cada profundidad. La referencia actual del método no contiene ningún número de hojas y dice: «No trate la profundidad como una promesa aritmética sobre el esfuerzo o los tokens». Sólo queda la orientación cualitativa: «Use un árbol poco profundo o un registro individual para una funcionalidad, una búsqueda de errores acotada o un documento». Un árbol orquestado está indicado cuando varios entregables coherentes se benefician de contextos nuevos o de una responsabilidad independiente. Una mayor profundidad sólo está justificada cuando sus ramas adicionales corresponden a límites reales de integración.

Cuando no indica ninguna profundidad, la referencia dice que se debe «elegir el árbol más pequeño que exponga cada entregable y punto de integración independientes». Si indica un número que no se ajusta al trabajo, ordena al agente que lo diga en lugar de rellenar: «Si la profundidad solicitada crearía hojas de relleno, indique la discrepancia y use la descomposición honesta más cercana». La profundidad describe el trabajo, por lo que inflar 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 aprobación, y el comando también debe terminar con el código 0 para que se considere aprobado. EVIDENCE comienza en pending. Después de una ejecución aprobada, el comprobador lo completa con una huella de la salida en lugar de la salida sin procesar. Un gate manual no tiene comando, por lo que se registra el hecho mínimo que demuestre el resultado. La skill incluye scripts/gate-check.mjs para hacerlo. Con --status, informa qué gates siguen abiertos sin ejecutar comandos ni modificar archivos, de modo que puede auditar una ejecución sin leer la transcripción. Sólo ejecuta comandos del ledger cuando se proporciona --approve, por lo que debe leer cada comando y cada script que invoque antes de proporcionarlo. Un scripts/gate-lint.mjs independiente comprueba la calidad de un ledger sin ejecutar nada.

La regla de generación de informes de SKILL.md cabe en una línea:

No redacte un informe de finalización mientras algún gate obligatorio no esté cumplido, se haya abandonado, aplazado o esté pendiente de una decisión del responsable.

Además, se indica al agente que debe "volver a medir cada número y cada afirmación de finalización inmediatamente antes de informar". Un gate no se cierra porque el agente se considere terminado. Para cerrarlo, se necesita una ejecución cuya salida coincida con EXPECT o no coincida con él.

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

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

Cuando un árbol es lo bastante amplio como para que las hojas se ejecuten en contextos independientes, esas hojas dejan de compartir supuestos. La referencia del método establece un contrato antes de la expansión: «Corrija los contratos antes de la expansión». El plan enumera todos los resultados obligatorios en PLAN.md y «después registra las interfaces, los formatos, los supuestos compartidos, las convenciones de error, la nomenclatura y la propiedad antes de que una hoja comience».

La razón es concreta. Dos subagentes a los que se les pide «añadir gestión de errores» inventarán dos formatos de error distintos, y ambas hojas superarán sus propias comprobaciones porque cada una es correcta de forma local. El fallo sólo aparece cuando se integran. Ese punto de integración corresponde a la capa superior, y la referencia de orquestación lo indica claramente: «Vuelva a verificar las hojas y después ejecute comprobaciones de interfaz, de extremo a extremo y de regresión».

En el modo orquestado, se indica al controlador que «entregue a cada hoja sólo el contrato compartido, su propiedad y dependencias exactas y su propio registro» y que «no filtre historiales no relacionados de otras hojas». El registro de cada hoja declara las rutas que puede modificar, y esas rutas OWNS no deben solaparse con las de ninguna otra hoja que se envíe al mismo tiempo. Cuando un subagente devuelve su resultado, el controlador debe «volver a ejecutar las comprobaciones ejecutables de la hoja devuelta, incluidas las comprobaciones ya realizadas», porque --status por sí solo no constituye una nueva verificación. Una hoja cuyos elementos se marcaron sin pruebas reales no superará esa nueva ejecución.

La orquestación tiene un límite mínimo. La referencia de orquestación indica: «Trabaje en solitario cuando un único contexto centrado pueda implementar y verificar la tarea sin ocultar entregables independientes». Cada subagente debe reconstruir desde cero su comprensión de la tarea. Por tanto, en una tarea pequeña, esa preparación cuesta más de lo que aporta la atención adicional.

¿Cómo se instala la skill unlazy?

La ruta admitida es la CLI de skills:

npx skills add Leonxlnx/unlazy

Añada -g para instalarla para un usuario o --all para todos los agentes que detecte la CLI. Este comando instala lo que haya actualmente en main. No existe una versión etiquetada, por lo que el README indica que debe fijar un commit exacto si necesita una instalación que no cambie con el tiempo.

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 otro lugar, normalmente porque el directorio de skills no existía con el nombre que suponía y git creó uno nuevo. Tampoco confíe únicamente en lo que indique el agente. Que un agente diga que la skill está instalada no demuestra que el archivo exista. El comprobador y el hook opcional necesitan Node 16 o una versión posterior, y no usan paquetes de runtime de terceros.

A fecha de 2026-10-11, el README documenta dos harnesses: Claude Code, donde se invoca la skill como /unlazy, y Codex CLI, donde se invoca como $unlazy. No documenta ninguna ruta para harnesses sin un cargador de skills, por lo que pegar SKILL.md en el archivo de reglas de otra herramienta no está probado. Si quiere saber qué hace que un SKILL.md se cargue de forma fiable, 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 terminar su turno. Este hook analiza el ledger de la sesión actual y el estado de dispatch, y bloquea la detención mientras haya gates pendientes. Así, el turno no puede terminar con una casilla sin comprobar. No ejecuta las comprobaciones ni realiza llamadas al modelo por su cuenta. Sin embargo, no es gratuito. La referencia sobre economía de tokens indica que «Un bloqueo provoca otra continuación del agente, que consume trabajo del modelo». 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. El README le pide instalar el hook sólo con el consentimiento del usuario. También le pide mantener .claude/settings.local.json, .unlazy/ y .unlazy-hook-state.json en las reglas de exclusión.

Tiene una válvula de escape, que es más importante de lo que parece. Si el agente no consigue avanzar en ningún gate durante seis detenciones bloqueadas consecutivas, el hook lo deja continuar en lugar de atraparlo. Las ediciones que sólo modifican metadatos no reinician ese contador. Una línea ABANDON: <gate> <reason> también permite terminar la sesión, pero como una transferencia visible y no como una aprobación. El gate abandonado se informa como un resultado no satisfactorio, no como trabajo terminado. Sin esas dos salidas, un gate imposible en su entorno consumiría tokens hasta que tuviera que terminar la sesión manualmente.

En Codex o en cualquier otro harness, install-hooks.mjs no tiene dónde instalarse, porque sólo escribe archivos de configuración de Claude. Aun así, obtiene el archivo de gates y las comprobaciones ejecutables, pero no hay nada que impida estructuralmente que el modelo termine el turno antes de tiempo. En ese caso, el archivo de gates es un documento que debe leer.

unlazy o ponytail: ¿cuál necesitas?

Estas dos habilidades tuvieron tendencia durante la misma temporada y actúan en direcciones opuestas respecto al volumen, por lo que es fácil confundirlas.

ponytail hace que el agente se comporte como un desarrollador sénior cuya primera pregunta sea 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 esté terminada y verificada.

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

Es posible ejecutar ambas, pero el orden importa. Define primero el alcance con la pregunta de ponytail y después entrega el alcance acordado a las comprobaciones de unlazy. Si lo haces al revés, crearás un árbol de hojas para tareas que ponytail habría eliminado y pagarás el esfuerzo adicional de todas ellas. Este orden es mi recomendación, no una integración documentada entre los dos proyectos.

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

El esfuerzo se mide en tokens y, si ejecuta un agente en un VPS con su propia clave de API, los tokens cuestan dinero. El proyecto ya no ofrece una cifra para indicar cuánto trabajo adicional añade unlazy.

Las versiones anteriores de esta guía incluían multiplicadores de tokens de salida y de coste basados en la comparación de seis ejecuciones de los autores. Desde entonces, los autores han retirado esas cifras. references/token-economy.md indica ahora que las instrucciones sin procesar, las trazas, las salidas y los registros de puntuación en los que se basaban no están en el repositorio, «por lo que esas cifras no se pueden reproducir aquí», y añade: «No las utilice como garantías del producto». La referencia del método va más lejos: «No trate la profundidad como una promesa aritmética sobre el esfuerzo o los tokens». Hemos eliminado las cifras en lugar de repetir datos que sus propios autores ya no respaldan.

Lo que la referencia todavía dice sobre el coste es orientativo. Su recomendación inicial es «trasladar la verificación repetida y determinista a comandos y mantener limitado el contexto de orquestación». El modo independiente consume tokens de salida adicionales dentro de un solo contexto. El modo orquestado añade contextos, y cada contexto nuevo lee el contrato y su propio registro antes de hacer algo útil. La referencia advierte en ambas direcciones: «No orqueste una tarea que una sola sesión centrada pueda implementar y verificar correctamente». También desaconseja mantener una compilación completa en un solo contexto sólo para evitar el coste de los subagentes cuando las unidades finales y los contratos están claros.

De esto se desprenden cuatro ajustes:

• Elija la menor profundidad cuyas unidades finales sean unidades de trabajo reales y deténgase ahí. La profundidad que no necesita es gasto que no necesita.
• Manténgase en modo independiente cuando una sola sesión centrada pueda compilar y verificar la tarea, porque allí la configuración del subagente cuesta más de lo que aporta el contexto nuevo.
• Instale el hook Stop si utiliza Claude Code. El hook no realiza llamadas al modelo por sí mismo, pero cada bloqueo devuelve el agente al trabajo, y ese trabajo se factura.
• Establezca 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 rechazar las detenciones prematuras es, por diseño, una skill que sigue trabajando. Los presupuestos y las alertas son una tarea distinta de la elaboración de instrucciones, 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 solía publicar su propia prueba, algo menos habitual de lo que debería. Desde entonces, los autores han retirado esa prueba, algo todavía menos habitual. El README ahora sólo indica que «Las versiones anteriores del README también citaban una comparación interna de seis ejecuciones» y que «Los artefactos sin procesar necesarios para reproducir esas proporciones y recuentos exactos no están en este repositorio». Su recomendación es: «Trate los resultados como información histórica de diseño, no como una garantía de rendimiento».

La configuración se conserva en research/validation-protocol.md: dos tareas de compilación, tres condiciones para cada una (sin skill, tree 3 y tree 6), y una carpeta y una sesión nuevas en cada ejecución. El protocolo la denomina «comparación exploratoria ejecutada por los mantenedores». Indica que las proporciones de tokens, los recuentos de defectos encontrados por el propio sistema, los fallos en tiempo de ejecución y los errores en los números del informe que produjo no se pueden reproducir ni auditar desde el repositorio. También indica que la comparación no debe describirse como una prueba de que unlazy cause una mejora concreta o un multiplicador de coste específico. Las versiones anteriores de esta guía incluían gráficos con los recuentos de cada ejecución de esa prueba. Tras la retirada por parte de los autores, los hemos eliminado.

Una lección de diseño sobrevivió a las cifras. La regla de «volver a medir cada cifra y cada afirmación de finalización inmediatamente antes de informar de ellas» sigue en SKILL.md, y la plantilla de gates advierte que no se debe copiar una cifra proporcionada en EXPECT como si fuera una prueba propia. Un resumen categórico basado en una compilación defectuosa es exactamente lo que los gates pretenden evitar.

Ahora, los límites. A fecha de 2026-10-11 no queda ningún resultado publicado que evaluar, sólo el método y un protocolo para repetir correctamente la prueba. Pruébelo con su propio trabajo: ejecute la misma tarea dos veces, una de forma normal y otra con un archivo de gates, y después cuente los gates que se cerraron con pruebas que pueda volver a ejecutar por su cuenta. Ese recuento es la única cifra de este ámbito que le corresponde.

FAQ

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

Es un método de descomposición. Una tarea sólo se divide en límites reales de dominio, componentes o verificación; la capa 1 es la tarea solicitada y cada hoja es un entregable coherente con sus propios criterios de validación. Las hojas adyacentes y pequeñas se combinan, y una hoja que oculta varios resultados independientes se vuelve a dividir. Cada capa situada por encima de las hojas integra y verifica: vuelve a comprobar los elementos secundarios y después ejecuta comprobaciones de interfaz, de extremo a extremo y de regresión. La profundidad se elige al invocar la skill, por ejemplo tree 5. Si no se especifica ninguna profundidad, la skill selecciona el árbol más pequeño que expone cada entregable y punto de integración independientes.

¿Funciona la skill unlazy fuera de Claude Code?

En parte. La skill está escrita en markdown y el README documenta Codex CLI junto con Claude Code, por lo que el árbol de profundidad, el archivo de criterios de validación, las comprobaciones ejecutables y las cuatro pasadas por hoja también funcionan allí. La documentación actual no cubre otros entornos de ejecución. La aplicación estricta es diferente. El hook Stop que bloquea el final de un turno mientras no se cumplan los criterios es una función de Claude Code, instalada con node <path-to-skill>/scripts/install-hooks.mjs. En los demás entornos, nada impide estructuralmente que el modelo termine el turno antes de tiempo; por tanto, usted debe leer el archivo de criterios y enviárselo de nuevo.

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

Actualmente nadie puede darle una cifra fiable. Las proporciones de tokens anteriores de los autores procedían de seis ejecuciones que no se pueden reproducir. La documentación actual indica que no deben usarse como garantías del producto ni interpretarse como una promesa aritmética sobre el esfuerzo o los tokens en función de la profundidad. La tendencia sí es clara. El modo en solitario añade salida dentro de un único contexto. El modo orquestado añade un contexto nuevo por hoja, que lee el contrato y su registro antes de trabajar. El hook Stop no realiza llamadas al modelo por sí mismo, pero cada bloqueo devuelve el agente al trabajo. Mídalo con su propia tarea y compárelo con su propia facturación.

¿Debo usar unlazy o ponytail?

Adapte la skill al fallo que tiene delante. ponytail está pensado para un agente que escribe demasiado, porque interpreta el papel de un desarrollador sénior que pregunta si el código debe existir y recurre primero a la biblioteca estándar. unlazy está pensado para un agente que termina demasiado poco de lo que se le pidió, porque fuerza la descomposición y se niega a cerrar un criterio sin pruebas. Si quiere usar ambas, delimite primero el alcance con ponytail y después entregue ese alcance a unlazy. Así evita pagar un multiplicador de esfuerzo por 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 clonar en un directorio que no existía es el error más habitual. Segundo, confirme que se escribió un archivo de criterios antes de iniciar el trabajo, porque el hook analiza el registro de la sesión y un GATES.md ausente no le deja nada que bloquear. Tercero, confirme dónde se instaló el hook: la ejecución normal de install-hooks.mjs sólo escribe en settings.local.json de este proyecto, por lo que otro proyecto necesita --global. Cuarto, recuerde que el mecanismo de liberación funciona según lo previsto. Seis detenciones bloqueadas consecutivas sin ningún avance en los criterios liberan al agente, y una línea ABANDON: <gate> <reason> finaliza deliberadamente el intento como una entrega visible que no constituye un éxito.