Prompt
Me estás ayudando a escribir un mensaje de commit claro y una descripción de pull request a partir de un diff. Sigue las convenciones de mi equipo.

Convención de commits (por ejemplo Conventional Commits) o "ninguna": {{convention}}
Por qué hice este cambio: la intención que un diff no puede mostrar: {{intent}}
El diff:
{{diff}}

Produce dos cosas:
1. Un mensaje de commit: una línea de asunto concisa (modo imperativo, unos 50 caracteres, siguiendo {{convention}} si se indica), una línea en blanco, y luego un cuerpo que explique qué cambió y por qué, ajustado a 72 caracteres. Referencia el issue como "[ISSUE]" para que yo lo complete.
2. Una descripción de PR: un resumen de un párrafo, una lista con viñetas de los cambios notables, una sección "Cómo probarlo" y una nota de "Riesgo / reversión".

Reglas:
- Describe solo lo que realmente está en el diff. No afirmes que se agregaron pruebas, se actualizó documentación o se corrigió un error a menos que el diff lo muestre. Marca como "[VERIFICAR]" cualquier cosa que no puedas confirmar a partir del diff.
- El porqué debe venir de mis notas de intención, no de tu suposición sobre mi motivación.
- Sin relleno, sin repetir el código línea por línea, sin tono de marketing.

Rellena tus datos y el prompt se actualiza al instante — luego cópialo.

Lo que obtienes (extracto)

feat(api): cachear consultas de permisos de usuario Las verificaciones de permisos consultaban la BD en cada solicitud, añadiendo latencia. Cachea los permisos resueltos por usuario durante 60s para reducir consultas redundantes. Cierra [ISSUE]. --- Resumen del PR: Agrega un cache en memoria de corta duración para las consultas de permisos. Cambios notables: - Nuevo PermissionCache con TTL de 60s - Cache invalidado al cambiar de rol Cómo probarlo: llama a /me dos veces; la segunda llamada debería saltarse la BD (ver el log de depuración). Riesgo / reversión: el cache está detrás del flag PERM_CACHE; desactívalo para revertir. [VERIFICAR] la invalidación en despliegues multi-instancia.

El flujo de trabajo completo

  1. Prepara el diff final en staging y anota en una línea por qué existe el cambio
  2. Genera el mensaje y la descripción, y luego corrige todo lo que el diff no respalde realmente
  3. Completa a mano los números de issue y cualquier marca "[VERIFICAR]"
  4. Mantén el razonamiento en el cuerpo: es la parte que los revisores y tu yo futuro realmente necesitan

Cuidado con

Un modelo que resume un diff afirmará alegremente que agregaste pruebas o corregiste un problema de seguridad que no corregiste. Un historial de commits es un registro permanente en el que otros confían, así que verifica cada afirmación contra el diff antes de confirmarlo.

Los diffs pueden contener secretos, claves o identificadores internos. No los pegues en una herramienta de consumo; usa una integración aprobada o sanéalos primero.

El modelo ve el qué pero no el porqué. Aporta tú la intención, o terminarás publicando mensajes que describen el cambio sin explicar la decisión detrás de él.

De dónde sale esto

Cada caso de uso de este sitio se basa en relatos reales de los desarrolladores de software en activo — no lo inventamos nosotros.

Más casos de uso de IA para los desarrolladores de software

← Los 6 casos de uso: cómo los desarrolladores de software usan la IA