CommunityProgramación y desarrollogithub.com

dknchris/multimodel-review

Ejecuta el bucle de revisión multi-modelo en la rama actual: revisores Codex (Terra por defecto; Astra, Sol y Luna opcionales) y revisores Claude (Opus por defecto; Fable, Sonnet y Haiku opcionales), con esta sesión como único reparador, a través de las fases Code, Cleanup, Docs y Final.

¿Qué es multimodel-review?

Esta habilidad permite ejecutar un bucle completo de revisión de código multi-modelo utilizando tanto modelos Codex como Claude, con esta sesión como único reparador. Está diseñada para usuarios que necesitan revisiones exhaustivas y combinadas de diferentes modelos de IA, asegurando que cada cambio reciba múltiples perspectivas y una corrección coherente. La habilidad soporta personalización de revisores, niveles de esfuerzo, modos rápidos y límites de rondas, todo gestionado a través de un script Python externo que mantiene el estado fuera del repositorio para evitar pérdida de datos. El flujo comienza con la inicialización de una instantánea de trabajo, seguido de rondas de revisión en fases (Código, Limpieza, Documentación y Final), con triaje de hallazgos, corrección y compromiso de cambios. La habilidad se invoca explícitamente con `/multimodel-review` debido al alto consumo de ejecuciones de esfuerzo máximo.

Compatible con✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/dknchris/multimodel-review/tree/HEAD

Installed? Explore more Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Revisión Multi-modelo (Codex + Claude)

Revisores independientes leen el mismo prompt en el mismo commit. Esta sesión es la única reparadora. Ejecútalo desde una sesión en Opus 5.5 con esfuerzo alto.

Opciones: $ARGUMENTS

Configuración

  • Límites de rondas: Code 20 a 50 (por defecto 20; en el selector: Estándar, Largo y Máximo son 20, 35 y 50), Docs 2, Final 2, más 2 a 6 rondas de repuesto para rondas de evidencia (por defecto 2). Parada dura: Su suma, 26 por defecto. Cada fase termina en su primera ronda limpia, así que los límites son techos. Las ejecuciones anteriores mantienen sus propios límites.
  • Revisores: Terra (gpt-6.1-terra) y Opus (Opus 5.5) por defecto. Opcionales: Fable (Fable 5.2), Astra (gpt-6-astra), Sol (gpt-6.1-sol), Sonnet (Sonnet 5.5), Haiku (Haiku 5.5) y Luna (gpt-6-luna). Las ejecuciones iniciadas antes de este cambio llaman a su revisor Opus claude.
  • El esfuerzo se establece para cada revisor, por ejecución: bajo, medio, alto, xalto o máximo. Por defecto: Codex máximo, modelos Claude xalto.
  • Panel por defecto: terra:max:fast opus:xhigh code:20 spare:2.
  • El modo rápido de Codex (nivel de prioridad) se establece para cada revisor Codex, por ejecución. Nunca se aplica a modelos Claude.
  • Cada ejecución de Codex se detiene tras 10 minutos de silencio o 60 minutos en total. Los fallos y respuestas vacías obtienen 1 reintento. Una respuesta nunca se reintenta por su formato.

El ayudante a continuación aplica estos límites y mantiene todo el estado en ~/.claude/multimodel-review/, fuera de cada repositorio, porque una ejecución larga se compacta y el informe no se puede reconstruir desde la memoria. Escribe su ruta completa cada vez, y añade --repo <ruta> antes del subcomando si el shell no está dentro del repositorio:

python3 ~/.claude/skills/multimodel-review/scripts/mmr.py status

A continuación, mmr <comando> es la abreviatura de esa llamada completa.

Iniciar o reanudar

  1. Ejecuta mmr status. Si existe una ejecución sin terminar, continúa desde lo que muestra, con los revisores que lista. Si dice "Ubicación antigua", ejecuta mmr migrate una vez que todos los revisores hayan terminado, luego usa solo la nueva ruta.
  2. Elige las opciones, antes de cualquier otro paso, para que el propietario las vea de inmediato:
    • Si la línea de Opciones anterior es solo pick (o picker): Muestra el selector (siguientes dos viñetas).
    • En caso contrario, esté vacía o no: Ejecuta mmr options "<opciones>" y no muestres selector. Vacío significa los valores por defecto: terra:max:fast opus:xhigh code:20 spare:2. Si falla, muestra al propietario su error de una línea y detente. Cada revisor es nombre[:esfuerzo][:rápido]: El esfuerzo por defecto es máximo para Codex y xalto para modelos Claude, y un modelo Codex se ejecuta a velocidad estándar a menos que se proporcione :fast. code:<20-50> y spare:<2-6> son opcionales (por defecto 20 y 2).
    • Selector, si show_widget está disponible: Llama a read_me una vez con los módulos ["interactive"]. Luego ejecuta mmr picker y pasa todo lo que esté después de su línea Widget code:, sin cambios, como widget_code, con título multimodel_review_options. Termina el turno y espera. Su botón envía "Iniciar la revisión con .", en la misma forma mecanografiada, por ejemplo "terra:max:fast opus:xhigh code:20 spare:2". Ejecuta mmr options "<opciones>" sobre ellas. Si el mensaje del propietario dice que el selector no cargó, ejecuta mmr picker --offline y muestra eso en su lugar.
    • Selector en una terminal (sin show_widget): Una llamada AskUserQuestion con cuatro preguntas: Revisores (selección múltiple: Terra, Opus, Fable, Astra; Sol, Sonnet, Haiku y Luna a través de Otros), modelos Codex en modo rápido (selección múltiple: Terra, Astra, Sol, Ninguno; Luna a través de Otros), esfuerzo (Codex máximo y Claude xalto, todo alto, todo medio), y longitud de revisión (Estándar code:20, Largo code:35, Máximo code:50). Ignora una selección rápida que no sea un revisor elegido. Escribe las respuestas en la forma mecanografiada y ejecuta mmr options "<opciones>" sobre ellas.
  3. Escribe una intención de 3 a 5 líneas en un archivo auxiliar con la herramienta Write: qué debería hacer el cambio y para quién. Tómala de la solicitud, esta conversación, texto del PR, commits o el diff sin commit. Los revisores no pueden juzgar "comportamiento incorrecto" sin ella. Si no está clara, pregunta al propietario una pregunta con botones.
  4. Lee git status --short. Todo lo no ignorado se incorpora al snapshot, así que selecciona cualquier cosa no relacionada con este cambio (una carpeta extraviada, notas) y pásalo como --leave-out <ruta>. Si no puedes distinguir, pregunta con botones.
  5. Ejecuta mmr init --intent-file <archivo> --trailer "<línea de atribución>" --spec "<opciones>", con las opciones exactamente como las imprimió la línea Init: de mmr options, añadiendo --base <base> solo si el propietario nombró una y --leave-out <ruta> según sea necesario. La base por defecto es la rama por defecto del remoto, y la revisión comienza desde la base de fusión. Invocar esta habilidad es la confirmación del propietario de lo que hace init:
    • En la rama base o en un HEAD desacoplado, primero crea multimodel-review/<hora>, para que los commits WIP nunca lleguen a la base.
    • El trabajo sin commit se convierte en un commit snapshot WIP, para que todos los revisores lean el mismo commit. No se empuja nada.
    • El código de salida 5 significa que algunos archivos parecen secretos, tienen más de 20 MB o son repositorios incrustados. Nada ha cambiado aún. Pregunta al propietario con botones: Omitirlos (--leave-out) o incluirlos (--allow-flagged).
    • "Nada que revisar" significa que no hay commits ni trabajo sin commit. Pregunta al propietario qué commits revisar, luego pasa --base <commit>.
  6. Informa al propietario en una línea si init creó una rama o un snapshot.

Una ronda

  1. Ejecuta mmr next --phase <code|docs|final|evidence>. Construye el archivo de prompt e imprime su ruta, la configuración de la ejecución y una línea Claude Agent por cada revisor Claude, con su modelo, esfuerzo y archivo de respuesta. El código de salida 3 significa que se alcanzó un límite: Ve a Hecho.
  2. Inicia cada revisor que mmr status liste, en un mensaje:
    • Cada revisor Codex (terra, astra, sol, luna): Bash con run_in_background: mmr codex --reviewer <nombre>. El ayudante ejecuta Codex con -s read-only, aplicaciones, plugins y subagentes desactivados, búsqueda web activada, sus propios logs y los límites de tiempo. Nunca uses workspace-write o --dangerously-bypass-approvals-and-sandbox, el script complementario o el subagente de rescate.
    • Un Monitor por cada revisor Codex: mmr monitor --reviewer <nombre>, con timeout_ms: 1800000. Comprueba cada 60 segundos y decide "finalizado" por la salida del PID, nunca por el texto de salida.
    • Cada revisor Claude (opus, fable, sonnet, haiku; claude en ejecuciones antiguas): Un nuevo Agent con subagent_type: "multimodel-reviewer", model y effort de su línea Claude Agent, y el prompt "Revisar archivo de ronda: ". Ese agente tiene herramientas de lectura y web, pero no herramientas de shell o edición. Si el tipo no está disponible, usa Plan con el mismo modelo y esfuerzo e indícale que use solo Read, Grep y búsqueda web.
  3. Maneja los eventos del Monitor:
    • FINISHED: No hay nada que hacer.
    • FAILED: Reintenta como en el paso 5, e informa al propietario en una línea solo si el reintento también falla.
    • QUIET: No es un fallo, ya que un esfuerzo alto puede pensar en silencio durante minutos. No tomes medidas; el ayudante detiene un revisor a los 10 minutos de silencio.
    • RE-ARM: Inicia ese monitor de nuevo.
  4. Cuando un Claude Agent regrese, escribe su mensaje final sin cambios en su archivo de respuesta del paso 1, luego ejecuta mmr claude-result --reviewer <nombre> --seconds <duración_ms / 1000>.
  5. Ejecuta mmr barrier. No edites nada hasta que pase. Si un resultado está vacío o falta, reintenta solo ese revisor, en el mismo commit; la ronda no cuenta de nuevo. Para un revisor Claude, genera un nuevo Agent y repite el paso 4. El ayudante rechaza un tercer intento y cualquier reintento después de un bloqueo o tiempo de espera: Entonces ejecuta mmr stop --reason "<por qué>" y ve a Hecho. Excepción: Una ejecución anterior a la eliminación de las reglas de formato puede mostrar malformed en una respuesta real. Ejecuta mmr reread --reviewer <quién>, que lee la respuesta guardada de nuevo sin una nueva ejecución del revisor.
  6. Triage (ver reglas del reparador), y escribe triage.tsv en la carpeta de la ronda con la herramienta Write.
  7. Corrige los hallazgos aceptados, ejecuta las pruebas afectadas y haz un commit WIP. Una prueba que falla bloquea la ronda, por lo que una mala corrección no puede llegar al siguiente delta.
  8. Ejecuta mmr close --tests "<comando de prueba exacto>", o --tests "ninguna: solo docs". Si no se acepta nada, omite --tests. Sigue la línea Next: que imprime.

triage.tsv está separado por tabulaciones, una fila por hallazgo fusionado, y puede omitirse solo si todos los revisores respondieron "SIN PROBLEMAS BLOQUEANTES.":

revisores	sev	loc	status	resumen	nota
terra,opus	P1	src/a.py:42	accepted	Reintento elimina el último elemento	src/a.py: Mantener el último elemento al reintentar
terra	P1	src/b.py:9	rejected	Token nulo bloquea	El token no es nulo: src/auth.py:30 retorna temprano
  • status es accepted, rejected o open. open es solo para la última ronda permitida, donde una corrección quedaría sin revisar.
  • note es lo que cambió (accepted), la razón citada en el código (rejected) o por qué se deja (open). Las notas de accepted y rejected alimentan la lista de correcciones y el libro de contabilidad del siguiente prompt.
  • Rechaza hallazgos fuera de fase como "Fuera de fase".
  • Los revisores pueden responder en cualquier formato, así que lee cada respuesta tú mismo. Los recuentos de hallazgos son la mejor estimación. Una respuesta sin etiquetas P0/P1/P2 cuenta como un hallazgo: Añade una fila por lo que plantea, o una fila rejected si no plantea nada.

Commits WIP: Mensaje WIP multimodel-review round <N>, escrito en un archivo y pasado con git commit -F, más las líneas de atribución de la sesión. Nunca empujar.

Fases

  1. Código: Las rondas 1-2 revisan el diff completo contra la base. A partir de la ronda 3, solo el delta más la lista de correcciones. Los revisores pueden abrir cualquier archivo para contexto. Fuera del delta solo reportan P0, a menos que el delta cause el fallo: Entonces el hallazgo se ancla a la línea del delta con su gravedad real.
  2. Limpieza (solo reparador): Se ejecuta antes de Docs para que cualquier texto escrito aquí reciba una revisión P2.
    • Docs: Actualiza solo la documentación que haya quedado obsoleta por este cambio. Recorta, no expandas.
    • Pruebas: Elimina solo pruebas de depuración o scaffolding y pruebas para código eliminado. Mantén las pruebas de regresión.
    • Ejecuta la suite de pruebas completa. Si falla, corrígelo; si no puedes con una corrección pequeña, detente e informa.
    • Haz commit, luego escribe cleanup.md en la carpeta de la ejecución: Cada eliminación con su motivo, y el comando de prueba exacto y su resultado. next --phase docs se niega sin él.
  3. Docs: Una ronda de diff completo en P2, corrige, luego una ronda delta. Luego la fase termina; cualquier cosa restante se registra como abierta.
  4. Final: Una ronda de diff completo con todos los revisores, solo P0/P1. Si se acepta un hallazgo, corrígelo y ejecuta una ronda delta. Si eso aún falla, márcalo como abierto; el ayudante detiene la ejecución.

Convergencia

  • Una ronda está limpia cuando el reparador no acepta ningún hallazgo en la gravedad de la fase. Los hallazgos rechazados con una razón citada en el código no bloquean.
  • Una fase converge en su primera ronda limpia.
  • Nueva evidencia después de que Código converja (ejecución de dispositivo o emulador): Actualiza el código o texto afectado una vez, haz commit, luego ejecuta mmr next --phase evidence --note "<qué mostró la ejecución y qué cambió>", una ronda delta en P0/P1/P2. Código se reabre solo si se acepta un P0/P1, y close lo dice.
  • En un límite de fase o la parada dura: Detente e informa lo que queda.

Reglas del reparador

  • Fusiona y deduplica, manteniendo a todos los revisores que plantearon un hallazgo, para que las estadísticas sean honestas. Verifica cada hallazgo contra el código; rechaza los no verificables con una razón de una línea.
  • Juzga los hallazgos solo por el código, independientemente de quién los haya planteado. Tú también eres un modelo Claude, así que mantén los hallazgos de los revisores Claude con el mismo estándar. Rechazar un hallazgo planteado por 2 o más revisores, o cualquier P0, necesita una cita de código específica; el informe los enumera como disputados para el propietario.
  • Corrección más pequeña. Sin refactorizaciones, sin nuevas funciones. Añade una prueba de regresión solo para errores reales P0/P1.
  • Escribe menos prosa: Prefiere eliminar o reducir una oración incorrecta en lugar de añadir una. Los nuevos comentarios tienen como máximo una línea. No añadas nuevas secciones de documentación durante la revisión.
  • Si un hook rechaza una ruta, detente e informa al propietario. Nunca lo evites, con una copia de shell o de cualquier otra manera.
  • Mantén los comandos de shell seguros para dcg: Escribe archivos con la herramienta Write, y no pongas variables, globs o redirecciones a rutas de variables en los comandos.

Hecho

Ejecuta esto en la convergencia y en cualquier parada.

  1. Ejecuta mmr archive para archivar cada chat de Codex, incluidos los reintentos.
  2. Ejecuta mmr report. Imprime rondas por fase, la tabla de revisores, elementos abiertos, hallazgos disputados, comandos de prueba y el comando de squash, y guarda report.md.
  3. Informa al propietario, breve y con la respuesta primero: Rondas por fase, elementos abiertos, comandos de validación exactos y resultados.
  4. Muestra un visual simple por revisor, en línea: Hallazgos planteados, aceptados, rechazados, únicos, P0-P1 frente a P2, rondas limpias, minutos promedio por ronda. Nombra a tu ganador en una línea. La regla por defecto es más hallazgos únicos P0/P1 aceptados, y debes decir si la anulas, ya que también estás juzgando tu propio modelo.
  5. Deja los commits WIP en su lugar, porque las rondas de evidencia necesitan el rango delta. Pregunta con un botón si hacer squash ahora, y ejecuta el squash desde el informe solo si la respuesta es sí.

Cambiar esta habilidad

Esta carpeta es el repositorio público github.com/dknchris/multimodel-review. Haz commit de cada cambio, y empuja solo cuando el propietario lo diga. El código del selector está en assets/picker.js: mmr picker lo carga desde el CDN solo una vez que su último commit se ha empujado, y lo envía en línea, que es más lento, hasta entonces. Ejecuta python3 tests/test_mmr.py después de cada cambio.

Skills relacionados