¿Qué hace Claudex Loop?
La conversación actual posee los requisitos, la planificación y la coordinación. El otro proveedor revisa el plan. Cualquiera de los dos puede construir; el proveedor que no construyó inspecciona el código final en una sesión nueva.
Resolver roles una vez
Identifica el anfitrión real a partir de tu entorno de ejecución, no del PATH, las habilidades instaladas, las conjeturas de nombre de modelo o el repositorio. Ambos CLIs pueden estar instalados. Usa host=claude en Claude Code y host=codex en Codex. Si la identidad del entorno de ejecución no está disponible, pregunta al usuario qué anfitrión está usando una vez.
| Anfitrión | Requisitos y plan | Revisor del plan | Constructor predeterminado | Inspector final |
|---|---|---|---|---|
| Claude Code | Sesión actual de Claude | Codex | Claude | Sesión nueva de Codex |
| Codex | Sesión actual de Codex | Claude | Codex | Sesión nueva de Claude |
Respeta builder=claude|codex. El inspector es siempre el otro proveedor. El anfitrión sigue siendo el coordinador incluso cuando el otro proveedor construye. Para intercambiar el planificador, inicia la conversación en el otro anfitrión; no finjas que un revisor CLI es la conversación de planificación del usuario.
La selección del modelo es independiente de los roles de los proveedores. Conserva el modelo seleccionado del anfitrión. Las llamadas CLI de revisión/construcción heredan su propia configuración a menos que se proporcionen reviewer_model, builder_model o inspector_model; asigna estos al --model del ejecutor para esa invocación. Aplica un *_effort explícito de manera similar. Fable 5.1 y GPT-6 Astra son opciones explícitas adecuadas, no fijaciones obligatorias. Un modelo en la interfaz de usuario del anfitrión no demuestra qué modelo usará un CLI separado. Informa la información del modelo solicitada y observada por separado; informa honestamente un valor predeterminado de CLI no resuelto. Nunca recurras silenciosamente a otro modelo/proveedor en caso de fallo.
Lee la referencia de entorno de ejecución antes de lanzar un CLI. Resuelve su ejecutor en relación con este SKILL.md instalado, nunca en relación con el proyecto que se está revisando. Usa rutas absolutas al iniciarlo.
Si el usuario proporciona codex_cli o claude_cli, asigna la ruta ejecutable del proveedor seleccionado a --cli. Una aplicación anfitriona puede tener un binario funcional más nuevo que el CLI en el PATH; verifica la ruta y la versión sin cambiar silenciosamente la instalación o configuración global.
Parámetros ajustables
| Argumento | Predeterminado | Significado |
|---|---|---|
PLAN_FILE / plan | PLAN.md | Ruta del plan utilizada en todo el proceso, incluida la entrega de la construcción |
LOG_FILE / log | PLAN-REVIEW-LOG.md | Transcripción de solo adición |
rounds / MAX_ROUNDS | 5 | Número máximo de rondas completadas de planificación-revisión |
builder | anfitrión | Proveedor que implementa el plan |
research | proporcional a la tarea | none, web o aceptación explícita deep |
mode | full | full incluye reconocimiento/entrevista; review comienza desde un plan existente |
inspect | on | off solo cuando el usuario se excluye explícitamente; regístralo |
MAX_FIX_ROUNDS | 2 | Intentos de corrección de construcción acotados antes de informar o tomar el control |
MAX_INSPECTION_ROUNDS | 2 | Inspección inicial más una después de las correcciones |
Informa los roles, rutas, límites de rondas, modelos solicitados y la exclusión de inspección antes de comenzar. Conserva la autorización existente: una solicitud de planificar no autoriza a construir; una solicitud de planificar e implementar sí lo hace. Realiza la preparación autorizada antes de buscar cualquier aprobación restante.
Fase 0 — Reconocimiento
Para proyectos existentes, inspecciona el código relevante, las dependencias, los llamadores y los escritores de estado compartido. Lee el CONTEXT.md / CONTEXT-MAP.md existente y las ADR relevantes. Para trabajo desde cero, investiga el arte previo, una pila razonable y modos de fallo concretos cuando sea útil. Respeta una profundidad de investigación explícita. La investigación profunda multiagente requiere aceptación explícita y una herramienta disponible; de lo contrario, utiliza la investigación dirigida compatible e informa la limitación. No requieras una herramienta Workflow propietaria ni fijes un modelo de agente de investigación.
Descubre habilidades relevantes a través del catálogo disponible del anfitrión y las ubicaciones de habilidades documentadas del otro proveedor cuando sean accesibles. Registra solo las dependencias propuestas relevantes. No asumas que las MCP, el navegador, las credenciales o las habilidades del anfitrión se transfieren al otro CLI. Verifica las capacidades de construcción requeridas antes de confiar en ellas.
Presenta un registro de supuestos con rutas de origen o enlaces de investigación. Solicita correcciones a incertidumbres materiales como un lote. Resuelve opciones rutinarias reversibles tú mismo cuando el usuario haya autorizado el trabajo; el silencio no es aprobación de una acción que requiera aprobación.
Fase 1 — Establecer requisitos
Mantén un mapa de decisiones corto y visible. Pregunta solo sobre decisiones no resueltas que cambien el resultado. Para cada pregunta consecuente, da la recomendación, por qué es importante y el costo de equivocarse. Agrupa preguntas independientes; haz las dependientes de forma secuencial. Si el código puede responder, inspecciónalo en su lugar. Ofrece "aceptar todas las recomendaciones restantes" cuando una larga lista de decisiones ralentizaría al usuario.
Respeta las definiciones de glosario existentes; resuelve el lenguaje de dominio ambiguo. Mantén el contexto del glosario de manera perezosa usando CONTEXT-FORMAT.md. Registra una ADR solo para compensaciones costosas de revertir y no obvias usando ADR-FORMAT.md.
Escribe el PLAN_FILE resuelto con:
- Objetivo y criterios de aceptación observables.
- Enfoque concreto, decisiones clave, compensaciones y no objetivos.
- Supuestos confirmados con fuentes y riesgos restantes.
- Requisitos de la cadena de herramientas por proveedor, si los hay.
- Verificación: comando(s) de prueba exacto(s), resultados esperados y comprobaciones manuales/visuales cuando sea necesario.
Deriva los comandos de prueba del repositorio cuando sea posible. Pregunta solo cuando no esté claro qué se considera éxito. Inicia el LOG_FILE de solo adición con roles, solicitudes de modelo, alcance, autorización y límites de rondas. Mantén los diagnósticos de ejecución fuera del directorio de trabajo.
Con mode=review, carga el plan proporcionado, completa solo las brechas materiales con el usuario según sea necesario y procede directamente a la revisión; no reinicies una entrevista de requisitos.
Fase 2 — Revisión independiente del plan
Usa el ejecutor compartido en modo review con el --host real, el --plan resuelto y el modelo/esfuerzo opcional. La primera ronda crea una sesión. Las rondas posteriores usan --resume <previous-successful-result.json> con el mismo proveedor/modelo/esfuerzo y un archivo --feedback creado por el anfitrión que contiene las decisiones. Nunca uses un ID de sesión adivinado, --last o una sesión de construcción como revisor.
Cada respuesta exitosa contiene un veredicto, hallazgos basados en evidencia, cobertura real y limitaciones. Conserva la respuesta completa y la ruta del resultado del ejecutor en LOG_FILE.
- APROBADO: sin defectos materiales no resueltos. La aprobación está vinculada a la ruta exacta del plan y a SHA256. Presenta consejos de baja prioridad y limitaciones restantes; cero hallazgos es válido y no es prueba de corrección exhaustiva.
- REVISAR: el anfitrión arbitra cada hallazgo. Implementa los cambios de plan justificados; rechaza las sugerencias no respaldadas con razones. Registra las decisiones y envía el plan revisado al mismo revisor. Evita volver a litigar puntos resueltos sin nueva evidencia.
- BLOQUEADO / proceso fallido / resultado malformado: nunca cuentes esto como aprobación. Explica la evidencia faltante real o la falla operativa. No quemes las rondas restantes en reintentos ciegos ni cambies de proveedor silenciosamente.
Detente en MAX_ROUNDS. Presenta los hallazgos no resueltos y la posición del anfitrión en lugar de fabricar convergencia. Un plan cambiado requiere otra revisión. Antes de construir, ejecuta la verificación de aprobación en el plan final. Si el usuario elige explícitamente proceder sin aprobación independiente, registra esa anulación y usa la ruta independiente de especificación no revisada; nunca lo etiquetes como aprobado.
Fase 3 — Construir e inspeccionar
Presenta el plan revisado, las mejoras y las limitaciones restantes. Si la implementación aún no está autorizada, solicita esa decisión final. Usa el constructor seleccionado, por defecto el anfitrión. Lee la referencia de construcción.
El anfitrión puede implementar directamente con sus herramientas normales. Para un constructor diferente, usa el modo build del ejecutor compartido. Cualquier camino debe capturar el commit previo a la construcción, preservar el trabajo no relacionado del usuario y llevar el mismo plan resuelto y contrato de verificación.
Ejecuta las comprobaciones de prueba acordadas, inspecciona todos los archivos cambiados y revisa el resultado a través del otro proveedor en una sesión nueva de inspect. Proporciona el commit previo a la construcción y la identidad del constructor. La reinsepección después de correcciones aceptadas también usa una sesión nueva. Registra los hallazgos y las decisiones; vuelve a ejecutar las comprobaciones de prueba afectadas después de las correcciones.
Si el coordinador asume la codificación, se ha convertido en constructor. Requiere una inspección nueva del otro proveedor de sus cambios; nunca describas la inspección anterior como si cubriera ediciones posteriores. Si ambos proveedores contribuyeron con código, registra la autoría y haz que cada uno inspeccione los cambios del otro; no afirmes que ningún modelo revisó de forma independiente el código que creó. Si el presupuesto de inspección se agota, informa los hallazgos restantes y las ediciones no revisadas explícitamente para la decisión del usuario.
Presenta el diff final, los resultados de la prueba, la cobertura de inspección, los hallazgos no resueltos, las desviaciones y las rondas utilizadas. Respeta la autorización de commit/push existente; de lo contrario, deja el diff concreto listo para su aprobación. La publicación externa nunca está implícita simplemente por ejecutar el bucle.