Mejores prompts para Codex: programación, debugging, tests y agentes

Analiza este repositorio.

No modifiques archivos todavía.

Explícame:

1. propósito del proyecto
2. arquitectura principal
3. entry points
4. módulos principales
5. flujo de datos
6. autenticación y autorización
7. acceso a base de datos
8. APIs externas
9. sistema de configuración
10. tests
11. build
12. deployment
13. zonas de mayor riesgo

Para cada punto
indica archivos
y funciones relevantes.

Termina con un diagrama textual
del flujo principal.

Necesito implementar:

[DESCRIBIR FEATURE]

No modifiques nada.

Investiga el repositorio
y dime:

- dónde vive actualmente
  la funcionalidad relacionada
- archivos afectados
- clases o funciones implicadas
- cómo fluye la información
- patrones similares existentes
- tests relacionados
- riesgos
- dependencias

Busca primero
si el proyecto ya resuelve
algo parecido.

Recomienda
el punto de implementación
más coherente
con la arquitectura actual.

Busca en todo el repositorio
todos los lugares donde:

[PATRÓN O COMPORTAMIENTO]

Clasifica los resultados por:

- archivo
- función o clase
- propósito
- similitudes
- diferencias
- riesgo

No modifiques código.

Quiero saber
si existe una implementación común
que podamos reutilizar.

Explícame cómo funciona:

[ARCHIVO / CLASE / FUNCIÓN]

No hagas cambios.

Describe:

1. qué problema resuelve
2. entradas
3. salidas
4. dependencias
5. efectos secundarios
6. estado que modifica
7. llamadas externas
8. errores posibles
9. tests asociados
10. qué partes son críticas

Después resume
el flujo paso a paso
en lenguaje simple.

No modifiques archivos todavía.

Necesitamos:

[OBJETIVO]

Crea un plan
de implementación.

Para cada paso indica:

- archivo
- clase o función
- cambio
- motivo
- dependencia
- riesgo
- test necesario
- forma de verificarlo

Prioriza:

1. reutilizar código existente
2. cambio mínimo
3. compatibilidad
4. reversibilidad

Marca cualquier decisión
que necesite confirmación.

Para implementar:

[OBJETIVO]

Propón tres enfoques posibles.

Para cada uno compara:

- complejidad
- archivos afectados
- mantenibilidad
- rendimiento
- compatibilidad
- riesgo de regresión
- facilidad de testing
- deuda técnica

No escribas código todavía.

Recomienda
la opción más simple
que satisfaga los requisitos.

Esta tarea es demasiado grande:

[DESCRIBIR TAREA]

Divídela
en unidades independientes
que puedan implementarse
y verificarse por separado.

Para cada unidad indica:

- objetivo
- dependencias
- archivos probables
- criterios de aceptación
- tests
- riesgo
- orden recomendado

Evita crear
un megaproyecto
que deba resolverse
en un solo cambio.

Objetivo:

[FEATURE]


Comportamiento actual:

[ACTUAL]


Comportamiento esperado:

[ESPERADO]


Restricciones:

- conserva APIs existentes
- no cambies código no relacionado
- reutiliza patrones actuales
- evita nuevas dependencias
  salvo necesidad real
- mantén compatibilidad
- no reduzcas seguridad


Criterios de aceptación:

1. [CRITERIO]
2. [CRITERIO]
3. [CRITERIO]


Implementa el cambio.

Después:

1. ejecuta tests relevantes
2. ejecuta lint/build
3. revisa git diff
4. busca regresiones
5. resume archivos modificados
6. informa cualquier riesgo restante.

Implementa:

[FEATURE]

Usa como referencia
la implementación existente en:

[RUTA / MÓDULO]

Mantén:

- misma arquitectura
- mismas convenciones
- mismo manejo de errores
- mismo patrón de tests

No copies código
innecesariamente.

Extrae reutilización
solo si realmente
simplifica ambas implementaciones.

Ejecuta
las verificaciones relevantes
antes de terminar.

Resuelve:

[PROBLEMA]

Prioridad:
cambio mínimo seguro.

No:

- refactorices módulos no relacionados
- renombres APIs públicas
- cambies formato masivamente
- añadas dependencias innecesarias
- reestructures el proyecto

Haz únicamente
los cambios necesarios
para satisfacer
el comportamiento esperado.

Después verifica
el caso afectado
y revisa el diff.

Añade validación para:

[DATO]

Requisitos:

- conserva comportamiento válido actual
- rechaza únicamente entradas inválidas
- utiliza el mecanismo
  de errores existente
- no dupliques validación
  si ya existe un helper
- añade tests
  para válido,
  inválido
  y edge cases

Implementa
y verifica.

Investiga este bug:

[SÍNTOMA]

Comportamiento esperado:

[ESPERADO]

Comportamiento real:

[REAL]

No modifiques código todavía.

Proceso obligatorio:

1. reproduce el fallo
2. identifica el flujo afectado
3. localiza el punto exacto
   donde diverge
   el comportamiento
4. busca logs
5. inspecciona datos
6. identifica la causa raíz
7. explica por qué ocurre

Después:

8. crea un test
   que reproduzca el bug
9. aplica la corrección mínima
10. ejecuta el test
11. ejecuta tests relacionados
12. revisa el diff

No te limites
a tratar el síntoma.

Analiza este error:

[ERROR]

No cambies ningún archivo.

Quiero únicamente:

- causa raíz más probable
- evidencia
- archivos involucrados
- flujo que produce el fallo
- condiciones necesarias
  para reproducirlo
- hipótesis descartadas
- forma mínima
  de confirmar el diagnóstico

Si falta información,
indica exactamente
qué evidencia necesitas.

Tenemos un fallo intermitente:

[SÍNTOMA]

Analiza posibles fuentes de no determinismo:

- concurrencia
- race conditions
- caché
- tiempo
- orden de eventos
- red
- estado compartido
- base de datos
- retries
- datos externos

No hagas cambios todavía.

Diseña primero
una estrategia
para reproducirlo
de forma determinista
o aumentar
la observabilidad.

Esta funcionalidad
antes funcionaba:

[FUNCIONALIDAD]

Ahora falla:

[SÍNTOMA]

Usa Git
para investigar
qué cambio reciente
pudo introducir
la regresión.

Compara:

- comportamiento anterior
- comportamiento actual
- archivos modificados
- tests afectados

Identifica
el commit o cambio
más probable.

No reviertas nada
automáticamente.

Propón
la corrección mínima.

Revisa:

[ARCHIVO / FEATURE / DIFF]

Analiza
la cobertura existente.

Identifica únicamente
tests de alto valor
que falten.

Prioriza:

- comportamiento público
- regresiones
- edge cases
- errores
- límites
- autorización
- persistencia

Evita tests
que solo repliquen
detalles internos.

No implementes todavía.

Dame una lista priorizada
de tests recomendados.

Este bug fue corregido:

[BUG]

Añade un test
que falle
con la implementación anterior
y pase
con la corrección actual.

El test debe:

- reproducir el escenario real
- verificar comportamiento observable
- evitar detalles internos
- ser determinista
- mantener el estilo
  de los tests existentes

Ejecuta
el nuevo test
y la suite relacionada.

Ejecuta los tests relevantes.

Para cada fallo:

1. identifica el test
2. agrupa fallos
   con causa común
3. determina si es:
   - bug real
   - test desactualizado
   - flaky test
   - error de entorno
4. muestra evidencia
5. recomienda
   la siguiente acción

No modifiques
tests únicamente
para hacerlos pasar.

Analiza esta función:

[RUTA / FUNCIÓN]

Enumera edge cases
reales para:

- valores vacíos
- límites
- tipos inesperados
- valores duplicados
- concurrencia
- errores externos
- estados inválidos

Selecciona
los casos
con mayor probabilidad
o impacto.

Añade únicamente
los tests
que aumenten
significativamente
la confianza.

Refactoriza:

[RUTA / COMPONENTE]

Objetivo:

[OBJETIVO]

Restricción principal:

NO cambies
el comportamiento observable.

Antes de editar:

1. identifica comportamiento público
2. identifica tests
3. detecta consumidores
4. explica invariantes

Después:

5. realiza el refactor
6. ejecuta tests
7. compara comportamiento
8. revisa el diff
9. informa cualquier cambio
   que pueda afectar compatibilidad.

Busca duplicación
entre:

[RUTAS]

No refactorices todavía.

Determina:

- qué lógica es realmente igual
- qué diferencias son intencionales
- qué podría extraerse
- qué sería peor abstraer

Propón
el refactor mínimo
que reduzca duplicación
sin crear
una abstracción genérica
difícil de mantener.

Analiza este módulo legado.

Objetivo:

modernizarlo
sin una reescritura total.

Identifica:

- APIs obsoletas
- duplicación
- acoplamiento
- puntos sin tests
- deuda técnica
- riesgos de compatibilidad

Propón
una migración incremental
en varias fases.

Cada fase
debe poder desplegarse
y verificarse
independientemente.

Haz una revisión
de seguridad
del cambio actual.

No modifiques archivos.

Prioriza:

- authentication bypass
- authorization failures
- injection
- secret exposure
- insecure file access
- SSRF
- unsafe redirects
- privilege escalation
- session problems
- unsafe deserialization
- data leakage

Para cada hallazgo:

- severidad
- archivo
- línea
- escenario explotable
- impacto
- corrección

No reportes
hipótesis puramente teóricas.

Revisa el repositorio
en busca de:

- API keys
- passwords
- access tokens
- private keys
- credentials
- secretos hardcoded
- archivos .env
  versionados por error

No muestres
el valor completo
de ningún secreto.

Informa:

- archivo
- tipo
- riesgo
- si parece real
  o ejemplo
- acción recomendada.

Mapea todas
las operaciones
que modifican estado.

Para cada una indica:

- entry point
- actor
- autenticación
- autorización
- recurso afectado
- validación
- posibilidad de acceso
  horizontal
- posibilidad de escalada
  vertical

Busca especialmente
acciones donde
el usuario pueda actuar
sobre recursos
que no le pertenecen.

No modifiques código.

Revisa
todos los cambios
sin commit.

Busca:

- bugs
- regresiones
- código accidental
- cambios fuera de alcance
- tests faltantes
- debug code
- archivos generados
- secretos
- dependencias inesperadas

No modifiques nada.

Entrega hallazgos
ordenados por severidad.

Compara
la rama actual
contra main.

Resume:

1. objetivo aparente
2. archivos cambiados
3. comportamiento nuevo
4. comportamiento eliminado
5. riesgos
6. cambios de datos
7. cambios de APIs
8. cobertura de tests
9. problemas encontrados

No te limites
al mensaje de commits.

Analiza el diff real.

Antes de crear un commit:

1. revisa git status
2. revisa git diff
3. ejecuta tests relevantes
4. busca debug code
5. busca archivos accidentales
6. confirma que el cambio
   está dentro del alcance

No hagas commit todavía.

Propón:

- resumen
- mensaje de commit
- archivos incluidos
- archivos que no deberían incluirse
- verificaciones realizadas.

Revisa este commit:

[HASH]

Analiza únicamente
los cambios introducidos
por ese commit.

Busca:

- bugs
- regresiones
- seguridad
- cambios de contratos
- pérdida de datos
- errores de concurrencia
- tests faltantes

No modifiques archivos.

Da prioridad
a problemas
que el autor
debería corregir.

Necesitamos integrar:

[API]

Antes de implementar:

1. localiza
   cómo este proyecto
   gestiona integraciones externas

2. identifica:
   - cliente HTTP
   - configuración
   - secretos
   - retries
   - timeouts
   - logging
   - manejo de errores

3. verifica
   la documentación actual
   de la API

4. propón
   el cambio mínimo

No inventes
endpoints
ni parámetros.

Después implementa
y añade tests
sin realizar
acciones destructivas reales.

Revisa este endpoint:

[RUTA]

Mapea:

- método
- autenticación
- autorización
- parámetros
- validación
- efectos secundarios
- consultas
- llamadas externas
- errores
- response
- tests

Busca:

- IDOR
- validación insuficiente
- errores silenciosos
- filtración de datos
- contratos inconsistentes
- casos sin cobertura.

Diseña una API para:

[CASO DE USO]

No escribas código todavía.

Define:

- recursos
- endpoints
- métodos
- autenticación
- autorización
- requests
- responses
- códigos HTTP
- validación
- errores
- paginación
- idempotencia
- versionado

Adáptala
a los patrones
ya existentes
en este repositorio.

Busca consultas SQL
en el módulo:

[RUTA]

Revisa:

- SQL injection
- N+1 queries
- índices
- full table scans
- joins costosos
- consultas duplicadas
- transacciones
- concurrencia
- bloqueo
- paginación
- manejo de errores

No optimices
por intuición.

Identifica primero
consultas
con riesgo real.

Necesitamos cambiar
el esquema:

[CAMBIO]

No implementes todavía.

Analiza:

- migración hacia adelante
- instalaciones existentes
- datos antiguos
- defaults
- índices
- locking
- compatibilidad
- rollback
- deploy gradual
- volumen de datos
- downtime

Propón
un plan seguro
e idempotente.

Esta operación
es lenta:

[OPERACIÓN]

No optimices
sin evidencia.

Primero:

1. encuentra consultas implicadas
2. identifica frecuencia
3. analiza volumen
4. revisa índices
5. busca N+1
6. busca consultas repetidas
7. identifica trabajo
   que podría evitarse

Propón
cómo medir
cada hipótesis
antes de cambiar código.

Corrige este problema
de interfaz:

[PROBLEMA]

Restricciones:

- no rediseñes
  componentes no relacionados
- conserva responsive
- conserva accesibilidad
- no cambies comportamiento
  de escritorio
  si el bug es móvil
- evita !important
  salvo necesidad demostrada
- reutiliza estilos existentes

Primero identifica
la causa exacta
en DOM/CSS/JS.

Después aplica
el cambio mínimo.

Revisa esta interfaz
desde el punto de vista
de accesibilidad.

Prioriza:

- HTML semántico
- navegación con teclado
- foco
- labels
- nombres accesibles
- contraste
- errores de formulario
- cambios dinámicos
- ARIA incorrecto
- orden lógico

No propongas ARIA
si HTML nativo
resuelve mejor el problema.

Devuelve hallazgos
por impacto.

Este formulario
puede enviarse
más de una vez.

Investiga:

- listeners duplicados
- estado del botón
- requests concurrentes
- retries
- event bubbling
- race conditions
- respuesta del backend

No apliques
solo un disable
visual
sin confirmar
la causa.

Corrige
el flujo completo
y añade
una prueba adecuada.

Analiza este plugin WordPress.

No modifiques archivos.

Mapea:

- bootstrap
- clases
- hooks
- shortcodes
- AJAX
- REST API
- cron
- tablas
- options
- metadata
- assets
- integraciones
- permisos
- seguridad

Indica
archivos y funciones
relevantes.

Haz una auditoría
de seguridad WordPress.

Revisa:

- validation
- sanitization
- escaping
- nonces
- capabilities
- AJAX
- REST permission_callback
- SQL
- uploads
- filesystem
- redirects
- secrets

No modifiques código.

Reporta únicamente
problemas reales
con:

- severidad
- archivo
- línea
- impacto
- corrección.

Analiza
la integración WooCommerce.

Mapea:

- hooks
- productos
- carrito
- checkout
- pedidos
- Mi Cuenta
- emails
- metadata
- endpoints
- cron

Busca:

- APIs obsoletas
- acceso directo
  a estructuras internas
- problemas de autorización
- incompatibilidades
- comportamiento
  sin tests.

No modifiques archivos.

Revisa esta rama
con cuatro subagentes.

explorer:
mapea los cambios
y code paths relacionados.

reviewer:
busca bugs
y regresiones.

security_reviewer:
busca vulnerabilidades
reales.

test_reviewer:
busca cobertura faltante.

Ejecuten
las partes independientes
en paralelo.

No modifiquen código.

Espera todos
los resultados.

Después:

1. elimina duplicados
2. resuelve contradicciones
3. ordena por severidad
4. incluye archivo y línea
5. devuelve únicamente
   hallazgos accionables.

Necesitamos entender:

[PROBLEMA]

Divide la investigación
entre tres agentes.

Agente 1:
arquitectura y código.

Agente 2:
tests y comportamiento actual.

Agente 3:
documentación externa
y APIs relevantes.

Trabajen en paralelo.

No editen archivos.

El agente principal
debe sintetizar
una única explicación
con evidencia.

Esta feature
puede dividirse.

Asigna:

Agente A:
backend.

Agente B:
frontend.

Agente C:
tests.

Antes de iniciar,
confirma que sus alcances
no requieren modificar
los mismos archivos.

Si existe solapamiento,
no paralelices
esa parte.

Después integra
los resultados
y ejecuta
la verificación completa.

Trabaja
en un Worktree aislado.

Objetivo:

[FEATURE]

No modifiques
mi checkout principal.

Proceso:

1. inspecciona estado inicial
2. implementa
3. añade tests
4. ejecuta verificaciones
5. revisa el diff

No hagas:

- push
- merge
- rebase
- deploy

Al final entrega:

- worktree usado
- archivos cambiados
- tests
- riesgos
- instrucciones
  para revisar el resultado.

Explora
dos implementaciones
para:

[PROBLEMA]

Opción A:
[ENFOQUE A]

Opción B:
[ENFOQUE B]

Usa trabajo aislado
para evitar interferencias.

Para cada opción:

- implementa prototipo
- ejecuta tests
- mide complejidad
- identifica riesgos

No mezcles
las implementaciones.

Compara ambas
antes de recomendar
una.

Revisa el diff actual.

Busca únicamente:

- bugs reales
- regresiones
- pérdida de datos
- problemas de seguridad
- errores de concurrencia
- contratos rotos
- edge cases importantes
- tests faltantes

No reportes:

- preferencias personales
- comentarios cosméticos
- cambios de estilo
  sin impacto

Ordena
los hallazgos
por severidad.

Revisa este cambio
desde el punto de vista
del usuario final.

Busca:

- workflows rotos
- estados imposibles
- errores no mostrados
- mensajes confusos
- pérdida de información
- retrocompatibilidad
- cambios inesperados
  de comportamiento

No te concentres
en estilo de código
salvo que produzca
un bug real.

Asume que este cambio
será desplegado
a producción.

Antes de aprobarlo,
revisa:

- migraciones
- rollback
- feature flags
- dependencias
- configuración
- compatibilidad
- logs
- observabilidad
- errores
- seguridad
- rendimiento
- datos existentes

Identifica blockers
y riesgos operacionales.

Este flujo
tiene problemas
de rendimiento:

[FLUJO]

No optimices todavía.

Investiga:

- número de consultas
- llamadas externas
- loops costosos
- serialización
- caché
- memoria
- operaciones repetidas
- trabajo bloqueante
- complejidad algorítmica

Separa:

1. evidencia
2. hipótesis
3. medición necesaria

Recomienda
qué medir primero.

Documenta este módulo:

[RUTA]

Basa la documentación
únicamente
en el comportamiento
real del código
y tests.

Incluye:

- propósito
- arquitectura
- flujo
- API pública
- configuración
- dependencias
- errores
- ejemplos mínimos
- limitaciones

No inventes
funcionalidades
no presentes
en el repositorio.

Antes de terminar:

1. revisa git diff
2. revisa git status
3. elimina debug code accidental
4. busca console.log
5. busca var_dump
6. busca print_r
7. busca TODO temporales
8. busca archivos generados
9. busca secretos
10. revisa dependencias añadidas
11. ejecuta formatter/linter
12. ejecuta tests relevantes

No hagas cambios
fuera del alcance.

Después resume:

- archivos modificados
- motivo
- tests ejecutados
- resultado
- riesgos restantes.