Sobre el proyecto

La Orquestación de Agentes de Repositorio es una Skill no oficial de la comunidad para Codex (licencia MIT) que mantiene las convenciones de entrega multi-agente dentro del repositorio en lugar de un servicio centralizado. Su objetivo es completar el trabajo del repositorio en los contextos adecuados con propiedad clara, verificación proporcional y entrega recuperable. El proyecto indica explícitamente que no otorga permisos, no desbloquea capacidades de producto y no reproduce ningún sistema de orquestación propietario. La documentación establece tres modos de propiedad — directa, de entrega y arquitectónica — como descripciones de quién toma las decisiones, no como números fijos de conversaciones. Las directrices cubren delegar trabajo separable, continuar trabajo listo para dependencias en lugar de sondear estados inmutados, mantener juicios de implementación y revisión independientes, y verificar identidad Git real y rutas exclusivas. Los escritores internos se describen como compartidores del árbol de su propietario con alcances disjuntos, mientras que los escritores de App que se ejecutan de forma independiente usan worktrees locales registrados separados. La revisión de diseño independiente es requerida por requisitos explícitos del usuario o del repositorio, o para riesgos transversales o irreversibles significativos. La instalación se realiza desde el checkout del código fuente con scripts/install_repository.py apuntando a una ruta de repositorio. Copia la Skill en .agents/skills/repo-agent-orchestration y actualiza idempotentemente un bloque marcado en AGENTS.md en la raíz del repositorio, preservando las reglas fuera de ese bloque. La bandera --dry-run previsualiza escrituras, y --check detecta deriva de archivos instalados o de perfiles sin modificar el objetivo. El instalador acepta opciones que cubren rama principal, raíz de worktree, prefijo de rama, política de raíz de worktree, política de host de tarea, política de modelo del controlador, configuraciones de modelo por rol, rutas de integración compartidas, política de continuidad y puertas de enlace externas. Las preferencias de modelo son app_default, que omite anulación de modelo y pensamiento; las actualizaciones preservan vinculaciones explícitas existentes excepto una preferencia de instalador retirada que migra de vuelta a app_default. Un adaptador estructurado opcional soporta tareas de App explícitamente solicitadas donde el host soporta saved-project y ruta local. Su constructor y validador manejan ocho tipos de paquetes — binding, write, review, update, design_handoff, delivery_update, design_reopen y design_decision — compartiendo un esquema. La documentación indica que el adaptador verifica contención de ruta, identidad de saved-project, rama Git actual y commit, revisión de solo lectura y configuración de informe preservada, pero no demuestra autorización de tarea, entrega real, calidad de revisión o aceptación, y que el campo DELIVERY de un informe es una ruta intencional en lugar de un recibo. La validación depende del descubrimiento unittest de la biblioteca estándar de Python, un validador de ejemplo y una demo local, con CI dirigida a Python 3.11 y 3.13; se requiere Git para pruebas de instalador y worktree. La demo crea un repositorio Git temporal y árboles de escritor aislados, demostrando solo verificaciones Git locales y de contrato, no creación de App, entrega de mensajes, modelos efectivos ni comportamiento real de agentes. Los casos conductuales se suministran para ejercicios que las afirmaciones de cadena no pueden demostrar. La guía de limpieza requiere una decisión explícita para cada worktree y rama poseída, eliminando solo residuo limpio, integrado o explícitamente abandonado validado a través del flujo de worktree de Git, y reteniendo residuo inseguro o útil con coordenadas exactas; no se incluye limpieza basada en antigüedad, eliminación forzada de trabajo recuperable, eliminación de ramas remotas, daemon en segundo plano o escalada automática de permisos. La estructura separa la Skill instalable, el instalador, el validador de ejemplo, la demo local, las entradas conductuales, un manual de escritorio opcional y pruebas deterministas.