super-review-council

Super Review Council / 超级审查会

Ejecuta un bucle de revisión y corrección multigente pesado y estructurado cuando el usuario solicita explícitamente este flujo de trabajo super-review-council. Es principalmente una revisión de código, pero también admite objetivos explícitos de bundle no-code congelados; no es el enrutamiento de aprobación auto_review de Guardian ni el comando codex review integrado.

Para ejecuciones explícitas de nivel superior, la forma predeterminada es un flujo de trabajo de cuatro agentes para cada fase sustantiva. Cuatro agentes inspeccionan el mismo bundle de cambios congelado, cuatro agentes ayudan a clasificar los hallazgos, cuatro agentes participan en la planificación/implementación de correcciones (donde la propiedad de escritura puede separarse) y cuatro agentes verifican el resultado antes de que el bucle se repita. El agente principal coordina, asigna propiedad, integra resultados y toma la decisión final sobre las correcciones aceptadas.

Úselo cuando:

• el usuario diga explícitamente super-review-council
• el usuario diga explícitamente Super Review Council
• el usuario diga explícitamente 超级审查会
• el usuario solicite explícitamente este flujo de trabajo pesado de consejo de revisión multigente
• un flujo de trabajo coordinador de nivel superior invoque explícitamente super-review-council como un pase secundario de solo lectura acotado

No active este skill para "revisión" simple, codex review integrado, Guardian auto_review, auto-revisión posterior a la edición normal, respuestas finales, commits, envíos, comprobaciones de CI, menciones de nombres de skills antiguos o mantenimiento ordinario de este archivo de skill a menos que el usuario haya solicitado este flujo de trabajo super-review-council para ese trabajo.

Cuando se active, primero indique que el skill super-review-council está activo e identifique el objetivo de revisión antes de comenzar el trabajo del revisor.

Atribución

Este skill se deriva del skill autoreview de openclaw/agent-skills con licencia MIT. El nombre heredado autoreview aparece aquí solo para atribución MIT, compatibilidad de rutas auxiliares/salidas/entornos y contextos de prohibición de flujos de trabajo anidados.

Flujo de Trabajo de Cuatro Agentes

Cuando el usuario diga super-review-council o 超级审查会, use cuatro agentes en paralelo para cada fase cuando el entorno admita subagentes. Prefiera agentes de estilo explorer para fases de solo lectura y agentes de estilo worker para fases de implementación. Los agentes de revisión, clasificación y planificación de correcciones (solo lectura) tienen como valor predeterminado un contexto mínimo de alcance de fase: identidad del objetivo congelado, rol, herramientas permitidas, prohibiciones y hallazgos/evidencia relevantes únicamente. Los agentes de verificación también tienen como valor predeterminado un contexto mínimo de alcance de fase, más cualquier comando de verificación explícitamente aprobado, rutas de salida, límites de escritura y requisitos de auditoría de desviación para esa fase. Las aprobaciones antiguas y las instrucciones de ejecución solo pueden pasarse como evidencia/procedencia, deben estar explícitamente etiquetadas como "contexto histórico solamente" y "sin autoridad", y no pueden otorgar permisos, aprobar ejecución degradada o riesgosa, autorizar escritura, pruebas, correcciones o flujos de trabajo anidados, ni anular el contrato de fase actual, las herramientas permitidas o las prohibiciones. Los agentes de trabajo pueden recibir contexto más rico solo cuando la corrección aceptada lo requiera, y ese contexto más rico está sujeto a los mismos límites de solo evidencia/procedencia.

Fase 0: verificación previa del objetivo. Antes de congelar el bundle o generar agentes, identifique el objetivo de revisión:

• si el usuario o un flujo de trabajo coordinador proporciona un archivo, directorio o bundle de revisión congelado explícito, ese objetivo explícito tiene prioridad sobre la detección de git del directorio de trabajo actual; canonice el objetivo y use el manifiesto de contenido/identidad hash incluso cuando el shell actual esté dentro de un repositorio git
• si está dentro de un repositorio git, registre la raíz del repositorio, la rama actual, el estado sucio/almacenado/no rastreado, la base upstream/base o base PR cuando esté disponible, y si el objetivo debe ser modo local, rama o commit
• si no está dentro de un repositorio git, proceda solo cuando el usuario haya proporcionado un archivo, directorio o bundle revisable explícito; canonice las rutas absolutas, rechace objetivos faltantes, enumere el contenido del directorio de manera determinista y deténgase para preguntar por un repositorio u objetivo explícito cuando no se haya proporcionado ninguno
• registre la identidad inmutable del objetivo antes de la Fase 1: SHA de commit para modo commit; refs base/head más un hash de diff para modo rama; hash de diff local/manifiesto no rastreado para modo local; o un hash de manifiesto de contenido para archivos, directorios y bundles que no sean git
• congele el bundle/fuente seleccionado antes de la Fase 1 e informe la identidad/hash del objetivo en la primera actualización visible para el usuario
• antes de la clasificación, planificación de correcciones e implementación, vuelva a calcular la identidad/hash del objetivo seleccionado y compárelo con la línea base actual del bucle de revisión congelado; inicialmente esta línea base es el valor de la Fase 0; este recálculo es solo una verificación de igualdad y no autoriza reemplazar la línea base, regenerar manifiestos, volver a congelar o reiniciar
• después de aplicar las correcciones aceptadas de la Fase 4, audite la identidad del objetivo/espacio de trabajo resultante contra la línea base anterior a la Fase 4, los ámbitos de escritura aceptados, las salidas aprobadas y las rutas prohibidas antes de registrar la identidad/hash del objetivo resultante como la línea base de verificación de la Fase 5 y la identidad inicial para el siguiente bucle de revisión; la desviación inesperada, fuera de alcance o prohibida debe ponerse en cuarentena y divulgarse, y bloquea la adopción de la línea base a menos que se apruebe explícitamente
• si alguna comparación de identidad del objetivo difiere debido a un cambio externo no aprobado, detenga esa fase, divulgue la identidad/hash esperada y observada más las rutas cambiadas cuando se conozcan, y requiera la aprobación explícita del usuario o coordinador antes de volver a congelar, reiniciar o adoptar una nueva línea base; en modo secundario de solo lectura, devuelva esto como un bloqueador al coordinador

Registro de subagentes nativos: la gestión del lado del coordinador es el control principal, no el bloqueo del sistema de archivos. Antes de que cada subagente nativo comience, el coordinador registra la fase y el rol, las herramientas declaradas, las acciones permitidas y prohibidas explícitas, las rutas de lectura/escritura permitidas, las rutas prohibidas, el perfil de sandbox y permisos cuando esté disponible, la identidad/hash del objetivo base, y el estado del repositorio/espacio de trabajo y los manifiestos, o una línea base de mutación de todo el espacio de trabajo equivalente suficiente para descubrir escrituras fuera del objetivo. Después de que el subagente regrese, compare la identidad del objetivo, los manifiestos de ruta permitida/prohibida, el estado del repositorio/espacio de trabajo y los metadatos de herramienta/sandbox/permisos con esa instantánea. Ponga en cuarentena, no confíe y divulgue cualquier discrepancia del objetivo, escritura inesperada dentro o fuera del objetivo, desviación de ruta permitida, toque de ruta prohibida, desviación de herramienta, expansión de permiso o sandbox, mutación inexplicada, desviación no autorizada o escrituras inesperadas antes de continuar. Los modos de solo lectura del sistema de archivos, los directorios inmutables y las restricciones de sandbox son salvaguardas o evidencia suplementarias útiles cuando estén disponibles, pero nunca reemplazan el contrato de solicitud del coordinador, el registro, la instantánea/auditoría de desviación, la decisión de cuarentena, la revisión de integración y la decisión final.

Manejo de fallos de fase: si algún agente requerido, motor auxiliar o trabajador genera un error, se agota el tiempo, viola el contrato de fase, devuelve campos obligatorios faltantes o produce una salida inutilizable, esa fase está incompleta. Ponga en cuarentena o ignore la salida sospechosa, divulgue el fallo y vuelva a intentar o reemplace al participante solo dentro del mismo contrato de fase y las restricciones del motor/modelo, o deténgase para obtener una aprobación explícita de modo degradado o un bloqueador. Nunca cuente la salida ausente, obsoleta o inutilizable como cobertura limpia de cuatro agentes.

Fase 1: revisión de cuatro agentes. Proporcione a cada revisor el mismo diff/bundle congelado y un enfoque principal:

• corrección y regresiones
• seguridad y límites de confianza
• pruebas, casos extremos y modos de fallo
• mantenibilidad, contratos de integración y comportamiento visible para el usuario

Restricciones de revisión:

• el motor de cada revisor debe estar restringido por el coordinador como revisor de solo lectura: el resumen de lanzamiento debe nombrar las herramientas/acciones de solo lectura permitidas, prohibir escrituras y comandos mutantes, prohibir la creación de revisiones/orquestación/agentes anidados y vincular al revisor al objetivo congelado; use sandbox, política de herramientas, indicadores auxiliares, controles de solo lectura del sistema de archivos o bundles inmutables solo como evidencia adicional opcional cuando esté disponible, pero nunca los requiera; no use un motor como revisor cuando el coordinador no pueda prohibir, observar y auditar razonablemente escrituras o desviaciones de herramientas
• los revisores no deben editar archivos, ejecutar formateadores, instalar paquetes, mutar el estado de git, enviar, confirmar o ejecutar comandos que escriban archivos
• los revisores pueden inspeccionar archivos, tipos, documentos, contratos de dependencia y documentos públicos actuales cuando sea necesario
• para revisiones de diff, rama, commit o parche, los revisores deben informar solo defectos procesables introducidos o expuestos por el cambio revisado
• cuando el objetivo congelado es un archivo completo, bundle no-code, plan, especificación, documentación o bundle de artefacto, los revisores informan defectos procesables presentes en ese artefacto contra su propósito y restricciones declarados en lugar de problemas solo de código o procedencia de diff
• los revisores no deben proponer reescrituras amplias, preferencias estilísticas o limpieza no relacionada

Fase 2: clasificación de cuatro agentes. Primero pase el guardia de objetivo obsoleto de la Fase 0, luego pida a cuatro agentes que clasifiquen de forma independiente los hallazgos combinados como aceptados, rechazados, duplicados o necesitan más evidencia. Los agentes de clasificación deben estar restringidos por el coordinador con el mismo contrato de solo lectura sin escritura, sin comandos mutantes, sin mutación de git, sin instalación, sin formateador, sin pruebas que escriban salida, sin revisión/orquestación/creación de agentes anidados utilizado para las fases de revisión de solo lectura; deben inspeccionar solo el objetivo congelado, los hallazgos combinados, la evidencia proporcionada y el contexto adyacente explícitamente dentro del alcance. El agente principal desduplica, rechaza hallazgos especulativos o de bajo valor, resuelve desacuerdos leyendo la ruta de código o artefacto revisada más el contexto adyacente dentro del alcance, y registra el conjunto de correcciones aceptadas.

Fase 3: planificación de correcciones de cuatro agentes. Primero pase el guardia de objetivo obsoleto de la Fase 0, luego pida a cuatro agentes de planificación de solo lectura que propongan planes de corrección mínimos y límites de propiedad. Los agentes de planificación de correcciones deben estar restringidos por el coordinador con el mismo contrato de solo lectura sin escritura, sin comandos mutantes, sin mutación de git, sin instalación, sin formateador, sin revisión/orquestación/creación de agentes anidados utilizado para las fases de revisión de solo lectura; no deben editar archivos, escribir artefactos, aplicar parches, ejecutar pruebas que escriban salida, no deben invocar super-review-council, no deben invocar autoreview heredado, no deben invocar goal-orchestrator, no deben invocar codex review integrado, abrir paneles de revisión ni crear agentes adicionales. Pueden inspeccionar el objetivo congelado y los hallazgos aceptados solo para proponer planes. Para objetivos no-code, los planes deben nombrar las secciones exactas del artefacto o las ediciones a nivel de línea en lugar de límites de propiedad de código. Prefiera correcciones pequeñas en el límite de propiedad correcto. No planifique refactorizaciones amplias a menos que solucione claramente la clase de error.

Fase 4: implementación de cuatro agentes. Primero pase el guardia de objetivo obsoleto de la Fase 0, luego use cuatro agentes de trabajo solo cuando las correcciones aceptadas se puedan dividir en ámbitos de escritura disjuntos. Asigne propiedad explícita de archivos/módulos a cada trabajador. Diga a cada trabajador que no está solo en la base de código, que no debe revertir ediciones hechas por otros y que debe adaptarse a cambios paralelos. Los trabajadores solo pueden editar archivos/módulos locales del repositorio asignados, deben evitar escrituras superpuestas, no deben formatear archivos no relacionados, no deben instalar paquetes o dependencias, y no deben enviar, confirmar, restablecer, desproteger/cambiar/restaurar, revertir, limpiar, stash, rebasar, fusionar, eliminar ramas/etiquetas, eliminar archivos no rastreados ni ejecutar comandos destructivos amplios del sistema de archivos como rm -rf o find -delete. Los trabajadores no deben invocar super-review-council, autoreview heredado, goal-orchestrator, codex review integrado, paneles de revisión, paneles de planificación ni agentes adicionales. Los trabajadores deben informar conflictos en lugar de resolverlos deshaciendo cambios del usuario o de pares. El agente principal revisa los parches de los trabajadores antes de aceptarlos. Si existen menos de cuatro ámbitos de escritura independientes, use los agentes restantes para verificación de solo lectura, planificación de pruebas o revisión de implementación en lugar de forzar ediciones superpuestas.

Fase 5: verificación de cuatro agentes. Primero pase el guardia de objetivo obsoleto contra la línea base de verificación actual, luego ejecute cuatro agentes de verificación en paralelo cuando sea posible:

• pruebas enfocadas y salida de comandos
• auditoría de diff para cambios no intencionados
• nueva verificación de regresión/seguridad de los hallazgos aceptados
• artefactos generados, documentos, instantáneas o consistencia de salida visible para el usuario

Los agentes de verificación deben lanzarse con rol explícito, identidad/hash de línea base, comandos y herramientas permitidos, rutas de lectura/escritura/salida permitidas, rutas y acciones prohibidas, tiempos de espera finitos y una prohibición de instalaciones, formateadores, mutación de git, comandos destructivos del sistema de archivos, revisión/orquestación anidada y agentes adicionales. Las pruebas o comandos de verificación solo pueden escribir en rutas aprobadas por el coordinador fuera de las raíces de destino protegidas a menos que la corrección aceptada sea propietaria explícita de esas salidas. La verificación que pueda mutar el objetivo revisado debe serializarse, o cualquier resultado de verificador paralelo recopilado contra la línea base anterior debe invalidarse y ejecutarse nuevamente contra la línea base posterior a la escritura auditada. Después de cada verificador o comando de prueba, el coordinador compara la identidad/hash del objetivo, los manifiestos de ruta permitida y prohibida, el estado del repositorio/espacio de trabajo y los artefactos de comando con la línea base de la Fase 5. La desviación inesperada, las escrituras prohibidas o las salidas no declaradas deben ponerse en cuarentena y divulgarse antes de continuar. Si las escrituras de verificación aprobadas cambian legítimamente el objetivo revisado, registre la identidad/hash del objetivo posterior a la verificación auditada como la identidad inicial para el siguiente bucle de revisión antes de que la Fase 6 vuelva a ejecutar la revisión. El modo secundario de solo lectura no ejecuta comandos de la Fase 5.

Fase 6: repetir. Después de que cualquier corrección aceptada cambie el objetivo revisado, incluido código, documentos, texto de skill, salida generada u otro contenido del bundle, vuelva a ejecutar la fase de revisión de cuatro agentes contra el diff o artefacto actualizado. Continúe hasta que el proceso de revisión/clasificación de cuatro agentes no deje hallazgos aceptados/procesables y las pruebas requeridas o las pruebas específicas del artefacto pasen. No repita indefinidamente: de forma predeterminada, deténgase después de tres ciclos completos de revisión/corrección a menos que el usuario solicite explícitamente continuar, y deténgase antes si el usuario cancela. En modo secundario de solo lectura, el bucle de repetición está deshabilitado; el coordinador principal controla la terminación del bucle.