Smart commit

Al analizar cambios para recomendar commits:

1. Ejecutar git status para ver todos los archivos modificados, agregados y eliminados
2. Ejecutar git diff para ver cambios unstaged y git diff --cached para ver cambios staged
3. Para cada archivo modificado, ejecutar git diff <archivo> para entender que cambio
4. Ejecutar git log --oneline -5 para ver el estilo de commits recientes y seguir la misma convención

Criterios de analisis

Evaluar los cambios y clasificarlos en grupos lógicos según:

• Propósito: Todos los cambios sirven al mismo objetivo? (bug fix, feature, refactor, docs, config, etc.)
• Alcance: Los cambios están en archivos/módulos relacionados o dispersos en áreas no relacionadas?
• Dependencias: Un cambio no tendría sentido sin otro? Esos van juntos.
• Reversibilidad: Cada grupo podría revertirse independientemente sin romper el proyecto?

Reglas de decisión

Recomendar UN SOLO commit cuando:

• Todos los cambios sirven al mismo propósito (ej: todos son parte de un bug fix o una feature)
• Los cambios son interdependientes y revertir uno sin los otros rompería cosas
• El diff total es pequeño (menos de ~50 líneas entre todos los archivos)

Recomendar MULTIPLES commits cuando:

• Los cambios sirven a propósitos diferentes (ej: un bug fix + un refactor + una feature nueva)
• Los archivos pertenecen a módulos o áreas no relacionadas del codebase
• Algunos cambios son cosméticos (formato, typos) mientras otros son funcionales
• Hay cambios de config/dependencias mezclados con cambios de lógica

Formato de salida

Presentar la recomendación de la siguiente manera. Los mensajes de commit SIEMPRE deben estar en inglés.

Si es un solo commit:

Recomendación: 1 commit

Archivos:
- lista de todos los archivos

Mensaje: <mensaje de commit en inglés siguiendo la convención del proyecto>

Si son multiples commits:

Recomendación: N commits

Commit 1:
  Archivos:
  - archivo1
  - archivo2
  Mensaje: <mensaje de commit en inglés siguiendo la convención del proyecto>

Commit 2:
  Archivos:
  - archivo3
  Mensaje: <mensaje de commit en inglés siguiendo la convención del proyecto>

...

Guias para mensajes de commit

Las cuatro reglas de un buen commit

1. Limitar la línea del subject a 50 caracteres
2. Capitalizar la línea del subject
3. No terminar la línea del subject con punto
4. Usar modo imperativo en la línea del subject

Verbos iniciales obligatorios

Cada mensaje de commit DEBE comenzar con uno de estos verbos en modo imperativo. Seleccionar el verbo según el tipo de cambio:

Verbo	Uso
Feat	Crear una capacidad: feature, test, dependencia
Fix	Corregir un issue: bug, typo, accidente, error
Docs	Cambio que SOLO es en documentación: archivos de ayuda
Refactor	Cambio que SOLO es un refactoring de código
Perf	Cambio que SOLO es de performance: acelerar código
Test	Cambio que SOLO es de pruebas: agregar, modificar o eliminar tests
Style	Cambio que SOLO es de estilo: formato, indentación, espacios en blanco

Formato del mensaje

<Verbo> <descripción corta en imperativo>

[Body opcional explicando qué y por qué]

Ejemplos:

• Feat: user authentication with JWT tokens
• Fix: null pointer exception in payment service
• Docs: update README with new API endpoints
• Refactor: database connection pool management
• Perf: optimize image loading with lazy loading
• Test: add unit tests for user service
• Style: reformat code with Prettier

Reglas adicionales

• Revisar git log --oneline -5 para contexto, pero SIEMPRE usar la convención de verbos definida arriba
• Los mensajes SIEMPRE en inglés, incluso si el usuario habla otro idioma
• Agregar body solo si el cambio es complejo y necesita explicación del qué y por qué

Ejecucion

Después de presentar la recomendación, NO ejecutar los commits. El usuario los hará manualmente. Solo presentar la recomendación con los archivos y mensajes sugeridos, y los comandos git que el usuario necesitaría ejecutar para cada commit.

IMPORTANTE: No agregar Co-Authored-By ni ningún otro trailer a los mensajes de commit generados por esta skill.