m_review — Revisión cruzada y mejora

¿Qué hace m_review — Revisión cruzada y mejora?

El revisor no corrige el código, solo deja notas de revisión. La corrección la realiza el agente que ejecuta este skill después de verificar directamente los señalamientos.

Entrada

• <ID>: ID del plan a revisar. Deben existir plan/<ID>_plan_*.md e impl/<ID>_impl_*.md.
• <agente>: claude | codex | agy. Como el objetivo es una revisión cruzada, se recomienda usar un agente diferente al que está ejecutando el skill.
• [modelo]: Si se omite, se usa el modelo por defecto de cada CLI.

Procedimiento

1. Fijar objetivo de revisión: Si hay cambios sin commit, pregunta primero si se desea commitear. Verifica el hash del commit de implementación en la nota de implementación.
2. Obtener nombre del modelo (se usa en el nombre del archivo):
   • codex: modelo especificado, si no, el de ~/.codex/config.toml en model
   • claude: clave modelUsage de la salida JSON
   • agy: modelo especificado, si no, el de ~/.gemini/settings.json en model, si no, default
3. Ejecutar revisor: Rellena {ID}, {PLAN}, {IMPL} (rutas reales), {COMMIT}, {REVIEWER} en review_prompt.md (de la carpeta de este skill) para crear un archivo temporal prompt.txt y guarda el resultado en review/<ID>_review_<agente>-<modelo>.md.
   • codex: codex exec --sandbox read-only --ephemeral [-m <modelo>] -o review/<archivo> - < prompt.txt
   • claude: claude -p --tools "Read,Grep,Glob" --output-format json [--model <modelo>] < prompt.txt → guarda result del JSON
   • agy: agy --sandbox --mode plan --output-format json [--model <modelo>] -p "$(cat prompt.txt)" < /dev/null → guarda response del JSON
   • La revisión toma de 5 a 15 minutos. Ejecutar en segundo plano o con un timeout largo. stdin debe conectarse a un archivo o /dev/null (de lo contrario codex espera entrada y se bloquea).
   • Al finalizar, verificar con git status que el revisor no haya modificado archivos.
4. Verificar señalamientos: Revisar cada punto directamente en el código y, si es posible, reproducirlo. Clasificar como válido / parcialmente válido / rechazado(motivo).
5. Mejora:
   • Problemas claros: corregir de inmediato y agregar una prueba de regresión en test_*.py para evitar recurrencias.
   • Problemas que requieren decisión: numerar como D1, D2… y preguntar al usuario uno a la vez. Ofrecer 2-3 opciones, marcando la recomendada con (recomendado) y su motivo. Si es necesario, verificar primero las opciones con un experimento.
6. Registro: Crear review/<ID>_refine_<agente>-<modelo>.md con la plantilla siguiente (basado en el agente que ejecutó este skill). Si se revisa el mismo ID nuevamente, agregar una sección ## <fecha> <nombre del archivo de notas> al archivo refine existente. Reflejar los cambios también en el documento del plan y la nota de implementación (marcar como pendiente, cambios respecto al plan, etc.). Para nombres de archivo y documentos modificados por otro agente, registrar los cambios según las reglas de AGENTS.md.
7. Finalización: Ejecutar de nuevo la autoverificación y las ejecuciones reales necesarias, luego informar los resultados y hacer commit (reglas de mensaje según AGENTS.md).

Plantilla (review/<ID>_refine_<agente>-<modelo>.md)

# [<ID>] Revisión aplicada

## <fecha> review/<ID>_review_<agente>-<modelo>.md

| ID | Juicio | Acción |
| :--- | :--- | :--- |
| <ID>-R1 | Válido (<método de verificación>) | ✅ <corrección> / ⏸ Decisión D1 / ✖ Rechazado: <motivo> |

### Decisiones
- ✅ **D1 (<ID>-R?)** <pregunta> → Decisión: <opción> (<motivo>)

### Verificación
<pruebas ejecutadas después de la corrección y resultados>