Reglas de revisión para Codex: convierte tus normas en feedback útil
Codex ya puede usar reglas personalizadas en AGENTS.md para revisar pull requests: una forma práctica de convertir criterios repetidos en feedback útil.
OpenAI ha publicado una novedad pequeña, pero muy interesante para equipos que trabajan con Codex: las revisiones de código pueden apoyarse en reglas personalizadas escritas en AGENTS.md.
La idea no es sustituir tests, linters ni revisión humana. La idea buena es otra: convertir esos criterios que repites una y otra vez en cada pull request en instrucciones claras que Codex pueda consultar cuando revisa cambios.
En una web real esto puede ahorrar bastante ruido. Piensa en normas como estas:
- no tocar el checkout de PrestaShop sin probar un pedido completo;
- no registrar datos personales en logs;
- mantener el prefijo
rfm_en funciones de WordPress; - no cambiar URLs públicas sin redirección;
- no modificar el comando de despliegue sin probar build local y staging.
Son reglas de negocio y de proyecto. No siempre encajan en ESLint, PHPStan o un test unitario, pero sí conviene que aparezcan en una revisión antes de mezclar código.
Qué pondría en AGENTS.md
Yo empezaría con dos o tres reglas, no con una enciclopedia. Una buena regla debe explicar el riesgo y el camino seguro:
## Code Review Rules
### Cambios en formularios de contacto
Si un cambio modifica validación, envío de email o almacenamiento de formularios:
- comprueba que no se registran datos personales en logs;
- revisa que los envíos duplicados siguen bloqueados;
- pide prueba manual del formulario en staging antes de producción.Esto es mucho más útil que escribir “revisa bien los formularios”. Codex necesita contexto concreto: dónde mirar, qué riesgo importa y qué alternativa es aceptable.
También conviene colocar las reglas cerca del código que gobiernan. Las normas generales pueden vivir en el AGENTS.md raíz del repositorio. Las de un módulo concreto pueden ir en una carpeta más específica. Así una regla de checkout no contamina una revisión de estilos CSS.
Dónde tiene sentido usarlo
Para una pyme o un proyecto freelance, lo usaría en tres zonas:
- Contratos que no deben romperse. URLs, campos de API, eventos, emails transaccionales o integraciones con terceros.
- Seguridad y privacidad. Logs, formularios, permisos, claves, datos de clientes y copias de seguridad.
- Convenciones locales. Prefijos, estructura de contenidos, comandos de deploy o reglas editoriales del proyecto.
El error habitual será meter demasiadas reglas. Si todo es importante, nada lo es. Mejor empezar por una incidencia que ya haya pasado o por una explicación que el responsable técnico repite a menudo en revisiones.
Mi recomendación práctica
Abre un pull request pequeño que debería activar una regla y otro que no debería activarla. Pide revisión a Codex y mira si el comentario ayuda o estorba. Si la regla genera ruido, no culpes al agente: probablemente está demasiado amplia o no explica el camino seguro.
Las reglas personalizadas funcionan mejor como memoria técnica del proyecto, no como una lista de deseos. Deben cubrir cosas caras de olvidar: compatibilidad, privacidad, despliegue, negocio y mantenimiento.
Para proyectos WordPress, PrestaShop, Astro o integraciones con APIs, esto puede ser muy útil: no porque Codex tenga siempre razón, sino porque obliga a escribir por adelantado qué no se debe romper.
Fuentes