hackycy/goal-loop

Goal Loop

Convierte documentos de decisión en tres artefactos:

• implementation-plan.md: contrato Gate estable, responde qué hacer, cuáles son los límites, cómo verificar y cuándo detenerse.
• goal-runbook.md: único libro de contabilidad de estado y evidencia, solo responde hasta dónde se ha ejecutado y qué evidencia existe.
• goal-prompt.md: prompt de entrada fijo, fácil de copiar manualmente, que solo apunta a los dos primeros documentos; no está vinculado a un Gate ni repite contratos.

Esta skill solo establece o verifica la superficie de control de ejecución; no implementa Gates ni rehace decisiones ya aprobadas.

Localizar entrada

El usuario proporciona un directorio de esfuerzo, map.md, ADR/spec o un implementation-plan.md existente. Analiza el directorio raíz del repositorio y localiza el esfuerzo; si no se puede localizar de forma única, se detiene y lista las rutas verificadas.

Lee los archivos CLAUDE.md, AGENTS.md, CONTEXT.md / CONTEXT-MAP.md aplicables, así como el mapa, spec, plan de implementación y sus ADR locales enlazados, decisions, issues y dependencias de aceptación. CONTEXT.md solo proporciona terminología y hechos del dominio; no genera Gates por sí mismo.

Soporta dos tipos de entrada convergida:

• Solo decisión: Gate, alcance, verificación y Exit pueden obtenerse de ADR aceptados, spec o issues resueltos.
• Wayfinder: el Not yet specified del mapa está vacío o es explícitamente "ninguno"; todas las decisiones que participan en el orden de ejecución y la aceptación están resueltas.

Si faltan enlaces de decisión locales, ADR no aceptados, decisions no resueltas, o el documento aún contiene TBD, TODO, preguntas abiertas, decisiones pendientes, se detiene e informa cada brecha. No se puede completar con experiencia decisiones de producto, políticas de aceptación o límites de reversión.

Compilar plan

Si implementation-plan.md no existe, lee completamente references/implementation-plan-schema.md y genera el plan a partir de las decisiones convergidas. Si ya existe, solo lo lee y valida, no lo sobrescribe.

El plan posee exclusivamente todos los contratos Gate estables: Objetivo, Entradas, Límite de alcance, Restricciones, Política de segmentación, Verificación, Regla de evidencia, Condiciones de parada, Reversión y Condiciones de salida. Los comandos del proyecto y las restricciones técnicas se escriben solo en el plan, no en el prompt fijo.

Si el plan antiguo contiene Current Execution State, puede importarse una vez al inicializar el runbook; los nombres, orden y estado de los Gates deben coincidir, y passed / blocked deben tener evidencia correspondiente. Después de la importación, el plan no se actualiza.

Compilar o verificar libro de contabilidad

Lee completamente references/runbook-schema.md.

Cuando goal-runbook.md no existe:

1. Lee los números, nombres, dependencias y ubicaciones de contrato de los Gates del plan.
2. Escribe la línea base de código fuente, el libro de contabilidad único de Goal y el registro de progreso de cada Gate.
3. Si no hay estado para importar, marca solo G0 como active y el resto como planned.
4. No copia el Objetivo, Restricciones, Verificación ni otros contratos de Gate del plan.

Cuando goal-runbook.md ya existe:

1. Compara el conjunto de rutas de código fuente y SHA-256; si el plan o las decisiones se han desviado, mantiene el libro de contabilidad intacto y se detiene.
2. Verifica el orden de los Gates, las referencias al plan, las dependencias estrictamente lineales, la máquina de estados y la evidencia en el registro de progreso.
3. El libro de contabilidad solo puede presentar passed* active planned*, passed* blocked planned* o passed+.

El plan es la única fuente de contratos; el libro de contabilidad es la única fuente de estado y evidencia. Ambos no deben copiarse campos ni escribirse estado duplicado.

Escribir prompt fijo

Lee completamente references/goal-prompt-template.md, reemplaza solo {{EFFORT_PATH}}, y escribe o sobrescribe goal-prompt.md.

El prompt fijo debe:

• Ser exactamente el mismo en todos los Gates del mismo esfuerzo;
• No mencionar Gates específicos como G0/G1, nombres de Gates ni Objetivo;
• No desarrollar Entradas, Restricciones, Verificación, Condiciones de parada, Reversión ni Condiciones de salida;
• Conservar el bucle de ejecución estable entre proyectos y las restricciones de comportamiento: segmentación mínima, control de alcance, cierre por fallo de verificación, división de responsabilidades, preservación de implementaciones no relacionadas, no debilitar pruebas, transferencia de aceptación manual y prohibición de push;
• Exigir que al iniciar un Goal se bloquee el único Gate activo actual y solo se ejecute ese Gate; en la aceptación manual, solicitar confirmación una sola vez, registrar primero la evidencia de transferencia, luego usar el estado final de éxito proporcionado por el agente anfitrión para finalizar este Goal (no marcarlo como blocked, paused ni continuar ejecutando), y finalmente generar un resultado de transferencia que incluya el Gate, el resultado de la automatización, el punto de entrada de aceptación, la lista mínima, el formato de respuesta explícito y "Goal finalizado, Gate aún activo", y finalizar la sesión normal. En ese momento, el Gate debe permanecer active; solo el usuario con un resultado de aceptación explícito puede activar manualmente un nuevo Goal posteriormente. Si no hay mecanismo de estado Goal, finaliza la tarea actual directamente sin crear un bucle de espera. Cuando un Gate pasa, marca el Gate actual como passed, el sucesor directo como active, resume la evidencia y finaliza explícitamente todo el Goal; no debe incluir el Gate sucesor en el mismo Goal.

goal-prompt.md es un archivo de conveniencia eliminable y recreable. No pertenece a la línea base de código fuente, no es referenciado por el plan ni el runbook, y no participa en la verificación de estado.

La respuesta final indica si se compiló o verificó, proporciona las rutas del plan, runbook y prompt fijo, y muestra el contenido del prompt. Si solo se optimizan artefactos, no se implementa ningún Gate.