Por qué está escrito así
Si solo explicas las reglas con palabras en un prompt de commit, el formato variará cada vez. Un día obtendrás "fix: ~", al siguiente "[Fix] ~", a veces solo un título y otras veces una lista de cinco líneas. En cuanto el formato del historial de un repositorio se vuelve inconsistente, pierde legitud.
Por eso, en el segundo párrafo incluimos dos ejemplos reales junto con las reglas. Al igual que las personas, la IA imita mucho mejor una frase completada que una instrucción abstracta como "menos de 50 caracteres, modo imperativo". Usamos dos ejemplos porque, si proporcionas solo uno, el modelo suele imitar también la temática de esa frase.
En la tarea, pedir 3 opciones y enfatizar que "deben tener diferentes perspectivas" evita que el modelo devuelva tres líneas con sinónimos idénticos. La indicación de explicar "por qué se cambió" en el formato define la razón de ser del cuerpo del commit. Qué cambió ya se ve en el diff; lo que debe quedar en el registro es la decisión y el contexto.
No omitas la frase del primer párrafo: "lo leerá alguien dentro de unos meses intentando entender por qué se modificó esta línea". Definir la audiencia condiciona automáticamente la longitud y el vocabulario. Sin esto, el título se llenará de abreviaturas o códigos internos que solo quien programa entiende en ese momento.
En las restricciones, la instrucción de "no inventar números de issue" previene un error muy común. Si dejas la generación automática sin restricciones, la IA agregará números de ticket ficticios pero creíbles. Delimitar los cambios con """ evita que los comentarios o strings dentro del diff se interpreten como instrucciones del prompt.
¿Términos desconocidos? Consulta Aha AI: few-shot, output-format
Comparado con un mal ejemplo
Escribe un commit para esto
(pegar diff)
Genera una línea genérica como "Update cart.js" o, por el contrario, una lista que repite literalmente las líneas modificadas. Sin conocer las convenciones del equipo, el prefijo y el idioma variarán cada vez, y el motivo del cambio no quedará registrado en ninguna parte, obligando a releer todo el código meses después.
Variaciones
Cuando se mezclan varias tareas en un solo commit
Evalúa primero si los siguientes cambios contienen tareas independientes mezcladas. Si están mezcladas, organízalas para dividirlas indicando "Orden del commit · Cambios incluidos · Título sugerido". Si no hace falta dividirlos, indícame que se puede mantener en un solo commit. Sigue las reglas de {{reglas del mensaje}}.
""" {{detalles del cambio}} """
Úsalo cuando hayas acumulado mucho trabajo y quieras dividirlo en commits atómicos. Al delegar el criterio de división, obtendrás unidades mucho más fáciles de revisar en un pull request.
Cuando necesitas el mensaje de commit en inglés
Genera 2 opciones de mensajes de commit en inglés basados en los siguientes cambios. El título debe estar en presente imperativo y no superar los 50 caracteres; el cuerpo debe tener saltos de línea cada 72 caracteres como máximo. Sigue las reglas de {{reglas del mensaje}}, pero redacta el texto en inglés. Elige vocabulario estándar y claro en lugar de expresiones rebuscadas.
""" {{detalles del cambio}} """
Útil para proyectos de código abierto o repositorios internacionales. Especificar el límite de caracteres por línea asegura que no se rompa la visualización en la terminal.
Notas por modelo
Si el diff es muy largo, pégalo archivo por archivo y al final pide: "Combina todo lo anterior en un único mensaje de commit"
Si pegas el diff tal cual, los abundantes símbolos pueden hacer que el modelo interprete la dirección del cambio al revés. Añadir una breve línea al principio como "El objetivo principal de este cambio es..." mejora enormemente la precisión.
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos