kairyou/agent-tools

Generador de Mensajes de Commit

Flujo de Trabajo

1. Ejecuta git diff --staged para inspeccionar los cambios preparados. Si está vacío, dile al usuario que ejecute git add primero y detente.
2. Determina el idioma de la descripción usando la Política de Idioma a continuación.
3. Genera el/los mensaje(s) y muéstralos para confirmación; no hagas commit inmediatamente. Cuando más de un enfoque sea razonable, preséntalos como una breve lista numerada (1), 2), …) para que el usuario pueda elegir respondiendo solo con el número. Un solo mensaje claro puede mostrarse por sí solo. El usuario también puede responder con una edición o su propio texto.
4. Ejecuta git commit -m solo después de que el usuario elija o confirme explícitamente — un número de la lista, "commit" u "ok" cuentan. No ejecutes git push a menos que el usuario lo pida explícitamente.

Política de Idioma

Usa este orden de prioridad para la descripción legible por humanos después de type(scope)::

1. Usa el idioma solicitado explícitamente por el usuario en esta interacción.
2. De lo contrario, usa la preferencia del repositorio en .agent-tools/config.jsonc, si define at-commit.language.
3. De lo contrario, usa la preferencia global en ~/.agent-tools/config.jsonc, si define at-commit.language.
4. De lo contrario, usa el idioma del texto de invocación real del usuario cuando contenga una solicitud clara e independiente en lenguaje natural. Ignora instrucciones de skill inyectadas, contenido citado o pegado, bloques de código, diferencias y salida de herramientas.
5. De lo contrario, coincide con el idioma dominante en los asuntos de commits recientes del repositorio.
6. Si ningún idioma dominante está claro, usa inglés por defecto.

Aplica este orden literalmente y detente en la primera coincidencia. Verifica los elementos 2 y 3 antes del elemento 4. Un comando slash o invocación de skill sin contenido no tiene idioma; continúa al elemento 5. Inspecciona como máximo los últimos 20 asuntos.

Mantén los tokens de sintaxis de Conventional Commits sin traducir: type, scope opcional, ! y BREAKING CHANGE. Mantén los identificadores, nombres de archivo, nombres de paquete, comandos, nombres de API y ámbitos en su idioma original.

Preferencia de Idioma Persistente

No escribas configuración durante la generación ordinaria de commits. Si el usuario pide explícitamente recordar un idioma de descripción de commit, ofrécete a persistirlo. Pregunta repositorio vs global cuando el ámbito sea ambiguo.

Para preferencia de repositorio, crea o actualiza .agent-tools/config.jsonc; para preferencia global, usa ~/.agent-tools/config.jsonc:

{
  "at-commit.language": "es"
}

Preserva claves no relacionadas y comentarios cuando sea práctico. No requiere configuración previa del instalador.

Reglas

Lee git diff --staged y genera un título de Conventional Commits que explique QUÉ cambió y, cuando sea útil, POR QUÉ.

• Título: type(scope): descripción, <= 74 caracteres, sin punto al final, sin prefijo, sin comillas, sin bloque de código.
• type: elige exactamente uno:
  • feat para una funcionalidad, fix para una corrección de error
  • refactor para reestructuración que preserva el comportamiento, perf para rendimiento
  • docs para cambios solo de documentación, style para cambios solo de formato
  • test para agregar o corregir pruebas, build para sistemas de compilación o dependencias, ci para scripts de CI
  • chore para cambios varios que no tocan src/test, revert para reversiones
• scope: nombre del módulo afectado opcional. Usa la convención de este repositorio. En monorepos, usa el nombre del directorio de la aplicación/paquete. Omítelo para cambios transversales o cuando no estés seguro.
• descripción: una frase verbo-objeto concisa en el idioma natural seleccionado. Evita relleno equivalente a "actualizar archivos", "este commit", "cambios varios" o "varios cambios". Preserva identificadores, nombres de función, nombres de archivo, nombres de paquete, comandos y APIs tal como están escritos.
• solo una línea: los mensajes de commit siempre contienen solo la línea del título. No escribas cuerpo ni pie de página. Comprime el POR QUÉ necesario en el título.
• cambios rupturistas: marca con type(scope)!: descripción, aún en una sola línea. No uses un pie de página BREAKING CHANGE.
• puntuación: usa puntuación ASCII.

Estrategia de Generación

Antes de escribir, identifica el hilo conductor de los cambios preparados.

• Línea principal: incluye solo la información necesaria para entender este commit. No apiles nombres a menos que uno sea el punto del cambio.
• Cambios significativos: busca cambios en lógica, contrato, compilación, puerta de calidad o comportamiento visible para el usuario. Usa eso para elegir type y decidir si se necesita !.

Disciplina de Contenido

El mensaje debe declarar hechos de código confirmados, no intenciones adivinadas.

• Prefiere cambios de comportamiento en src y test: la documentación es solo contexto de apoyo. No infieras QUÉ solo de la documentación.
• El contexto del usuario supera a la documentación: los objetivos explícitos del usuario pueden ayudar a elegir POR QUÉ y la redacción, pero QUÉ y ámbito aún provienen de la diferencia preparada. No incluyas cambios solo de contexto ausentes en la diferencia. Si el contexto y la diferencia entran en conflicto, sigue la diferencia y pide confirmación.
• Eliminaciones y renombres: cuando el propósito no pueda confirmarse a partir de las relaciones del código, indica solo lo que la diferencia prueba, como "eliminar X" o "renombrar X a Y". No afirmes reemplazo, migración o causalidad a menos que el código lo pruebe.
• Múltiples cambios con un mismo objetivo: proporciona un mensaje de resumen cuando los cambios sirvan claramente al mismo objetivo, como una corrección de calidad o compilación. Sugiere dividir solo cuando mejore materialmente la revisión o el rollback.
• Cambios preparados no relacionados: proporciona mensajes divididos para cada unidad coherente más un mensaje de resumen conservador. Deja que el usuario elija dividir o resumir en lugar de diferir el resumen a otra interacción.
• Propietario o intención no clara: lista los archivos que necesitan confirmación en lugar de forzar un mensaje vago. Prefiere confirmación o división sobre palabras débiles como "actualizar", "ajustar" o "modificar" cuando la intención no esté clara.