Sesiones respaldadas por archivos, no por la memoria del chat.
repo-harness convierte las sesiones de código de Claude y Codex en un flujo reproducible y local al repositorio. Entrega al agente un plan o sprint aprobado — tu bucle es solo review y next.
El chat olvida. El repositorio recuerda.
El mismo problema de coordinación, de dos maneras. repo-harness saca la fuente de verdad del hilo y la lleva a archivos que cada agente — y cada humano — puede leer.
- El contexto se evapora cuando una sesión termina o llega a su límite
- Cada sesión vuelve a deducir la estructura con bucles de grep y lectura
- No queda registro duradero de qué se decidió, ni por qué
- Claude y Codex se desincronizan entre hilos
- Revisar significa releer toda la conversación
- Retoma el paso siguiente exacto desde .ai/harness/handoff/
- Un contexto raíz estable de ~12 KB más un índice CodeGraph
- Planes, contratos, comprobaciones y revisiones viven en el repositorio
- Claude y Codex leen primero los mismos artefactos fuente
- Revisa con una sola Human Review Card y evidencia de máquina
La superficie es deliberadamente pequeña.
Inspecciona un repositorio, instala archivos de flujo locales al repositorio, enruta eventos del host mediante hooks y mantén las superficies del flujo coherentes entre Claude, Codex y las personas.
Sesiones respaldadas por archivos
Los traspasos, planes y paquetes de reanudación viven en el repositorio. Una sesión puede terminar a mitad de tarea; la siguiente reanuda en el paso exacto, los bloqueos y los archivos cambiados.
Frugal en tokens por diseño
Un contexto raíz estable de ~12 KB más un índice CodeGraph para consultas estructurales — en vez de bucles de grep y lectura que reescanean el repositorio cada sesión.
Hooks que protegen y trazan
Ocho rutas gestionadas avisan, bloquean, trazan y traspasan el trabajo. Las barreras de edición se mantienen hasta aprobar el plan; las de « hecho » verifican evidencia respaldada por archivos.
Una sola Human Review Card
Una superficie de decisión de una pantalla por tarea: veredicto, archivos previstos vs reales, comandos superados, riesgo residual y rollback.
Worktrees aislados
Los agentes trabajan en una rama o worktree vinculados, limitados a las rutas que permite el contrato — el estado modificado ajeno queda protegido.
Local y auditable
La verdad duradera son los archivos del repositorio, no el historial de chat ni hilos alojados. El sidecar MCP opcional solo expone artefactos de flujo — sin escrituras de fuente, sin shell.
Local, auditable, nativo para agentes.
Ocho capas, una fuente de verdad. La CLI orquesta; los contratos y el sistema de archivado mantienen el estado duradero; la capa de verificación prueba el trabajo — y ChatGPT Pro planifica en local mientras Claude o Codex ejecuta.
Una cadena en capas, de principio a fin.
La cadena de planificación es deliberadamente escalonada. Cada paso escribe un artefacto listo para decidir que el siguiente agente lee primero — el chat nunca es la fuente de verdad.
Mapea el terreno: los archivos, superficies y el código previo que toca el cambio.
Rastrea el impacto: llamadores, llamados y la cadena de causas detrás.
Decisión y justificación: el enfoque elegido, y por qué — registrado para el siguiente agente.
Un encuadre guiado y luego un PRD de capa superior bajo plans/prds/.
El PRD se convierte en un sprint con líneas de aceptación verificables por máquina.
Un prompt /goal acotado recorre cada porción del sprint por el bucle, en cualquiera de los dos agentes.
Acepta solo cuando la revisión recomiende aprobar, el veredicto de la tarjeta sea aprobado y la aceptación externa pase. Luego inspecciona el contrato, la última traza y los archivos cambiados.
Planifica con ChatGPT Pro. Ejecuta con Claude o Codex.
El sidecar opcional repo-harness mcp expone solo artefactos de flujo a los clientes MCP. ChatGPT Pro planifica sobre el estado real del repositorio y lleva una idea por PRD → Sprint → traspaso Goal — luego tu sesión existente de Claude o Codex ejecuta el sprint respaldado por archivos.
- 1 Leer el estado del repositorio
ChatGPT lee los archivos de flujo a través del sidecar MCP — planes, contratos, comprobaciones, traspasos.
- 2 Escribir el PRD
write_prd_from_idea redacta un PRD listo para decidir bajo plans/prds/.
- 3 Escribir el Sprint
write_checklist_sprint lo convierte en un backlog ordenado con aceptación verificable por máquina.
- 4 Preparar el traspaso
prepare_codex_goal_from_sprint escribe .ai/harness/handoff/codex-goal.md.
- 5 Claude o Codex ejecuta
Tu sesión existente de Claude o Codex ejecuta el prompt /goal nativo del host y prepara cada fase de sprint completada.
Ocho rutas de hook gestionadas.
El adaptador instalado posee ocho rutas. La tupla event + routeId + matcher es el contrato estable — avisan, bloquean, trazan y traspasan el trabajo entre sesiones.
las rutas de protección fallan en cerrado — las barreras requeridas bloquean cuando faltan sus scripts.
Acepta o rechaza desde una pantalla.
Cada tarea escribe una Human Review Card — la superficie de decisión de una pantalla. Ve qué cambió, por qué estaba en alcance, qué lo verificó, qué riesgo queda y cómo revertirlo.
Acepta solo cuando la revisión recomiende aprobar, el veredicto de la tarjeta sea aprobado y la aceptación externa sea aprobada, not_required o una anulación manual explícita.
Impulsado por Bun. Un comando para arrancar.
El instalador por defecto corre sobre Bun — no necesita configurar Node, y te instala Bun si falta. ¿Ya usas Node? También funciona. Arranca el runtime una vez y luego previsualiza el contrato local al repositorio con un dry run antes de aplicar nada.
repo-harness adopt --dry-run desde la raíz del repositorio. Informa de cada archivo que se crearía o refrescaría — aplica solo cuando el informe se vea bien.Construido sobre el buen trabajo de otros.
Estas skills, repos y runtimes dieron forma al contrato de flujo mientras se diseñaba y publicaba repo-harness. Se reconocen aquí como influencias, no como dependencias empaquetadas ordinarias.
El método de due diligence P1/P2/P3 y la práctica Geju tras la disciplina de planificación, rastreo y justificación de decisiones.
Las skills think, hunt, check y health para planificación diaria, cacería de bugs, verificación y sincronización de skills Codex-first.
Descubrimiento de producto, revisión de plan y diseño, higiene de docs tras el lanzamiento, sincronización de conocimiento y memoria de repo a largo plazo.
Diagramas de arquitectura y de flujo del sistema legibles.
Navegación con reconocimiento de símbolos, rastreo de impacto y comprobaciones de preparación.
Agente de ejecución principal para implementación y verificación locales al repo.
Cuando Codex contribuye de forma sustancial a un commit, este lleva Co-authored-by: codex <codex@openai.com> — opt-in y visible por commit.
Haz que tu próxima sesión de agente sea reanudable.
Arranca el runtime, previsualiza el contrato con un dry run y luego prueba el flujo. Gratis y de código abierto bajo MIT.