--- name: skill-commit description: > Buenas prácticas para crear commits de git claros, atómicos y bien estructurados en español. Activa esta skill siempre que el usuario pida hacer un commit, confirmar cambios, guardar cambios en git, o cualquier variación de "haz commit", "commitea", "sube los cambios", "guarda en git", "git commit", etc. También cuando el usuario pida revisar o mejorar un mensaje de commit existente. --- # Commits en Git — Buenas Prácticas El objetivo de un buen commit es que cualquier persona del equipo (o tú mismo dentro de 6 meses) pueda entender qué se cambió y por qué con solo leer el historial de git. Un commit bien hecho facilita las revisiones de código, simplifica los reverts y hace que el proyecto sea más mantenible. ## Estructura del mensaje de commit Usa el formato de **Conventional Commits** adaptado al español: ``` (<ámbito>): ``` **Ejemplo 1:** ``` feat(facturas): añadir campo de descuento por pronto pago Se añade un nuevo campo en el modelo de factura que permite aplicar un porcentaje de descuento cuando el cliente paga antes de la fecha de vencimiento. ``` **Ejemplo 2:** ``` fix(informes): corregir cálculo de IVA en informe trimestral El IVA se estaba calculando sobre el total con descuento en lugar de sobre la base imponible. Ahora se aplica correctamente. ``` **Ejemplo 3 (simple):** ``` docs(readme): actualizar instrucciones de instalación ``` ## Código de tarea en el commit Cuando el usuario proporcione un **código de tarea** (por ejemplo, un número de issue o tarea del roadmap como `4543`, `#1234`, `TASK-567`, etc.), este código debe incluirse en el **título del commit**, justo después del tipo (y ámbito si lo hay), antes de la descripción. Solo se incluye el código numérico o identificador, sin enlaces ni texto adicional. **Formato con código de tarea:** ``` : ``` **Formato con código de tarea y ámbito:** ``` (<ámbito>): ``` **Ejemplos con código de tarea:** ``` feat: 4543 añadir filtro por fecha de pago en las listas de anticipos de clientes y proveedores ``` ``` fix: 1287 corregir cálculo de IVA en informe trimestral ``` ``` feat(facturas): 3201 añadir campo de descuento por pronto pago ``` Si el usuario no menciona ningún código de tarea, el commit se escribe sin él, siguiendo el formato estándar. ## Tipos de commit Estos son los tipos que debes usar. Elegir el tipo correcto ayuda a generar changelogs automáticos y a entender el historial de un vistazo: - **feat**: nueva funcionalidad o característica - **fix**: corrección de un error o bug - **docs**: cambios solo en documentación - **style**: formato, punto y coma faltante, etc. (sin cambios en lógica) - **refactor**: reestructuración de código sin cambiar comportamiento - **test**: añadir o corregir tests - **chore**: tareas de mantenimiento (dependencias, configuración, CI, etc.) - **perf**: mejora de rendimiento ## Reglas para un buen mensaje La primera línea es lo más importante porque es lo que aparece en `git log --oneline`, en las interfaces de GitHub y en las revisiones de código: - Escríbela en **imperativo**: "añadir", "corregir", "eliminar" (no "añadido", "corregido") - Máximo **72 caracteres** en la primera línea - No termines con punto la primera línea - Escribe en **minúsculas** (salvo nombres propios o acrónimos) El cuerpo es opcional pero muy valioso cuando el cambio no es trivial. Úsalo para explicar el **por qué** del cambio, no solo el **qué** (el qué ya se ve en el diff). Sepáralo de la primera línea con una línea en blanco. ## Commits atómicos Cada commit debería representar **un solo cambio lógico**. Esto es importante porque permite hacer `git revert` de un cambio concreto sin arrastrar otros, y hace que las revisiones de código sean mucho más fáciles de seguir. Señales de que un commit es demasiado grande: - Necesitas usar "y" en la descripción ("añadir campo X **y** corregir validación Y") - Mezcla cambios funcionales con cambios de formato - Toca muchos archivos sin relación entre sí Si tienes cambios mezclados en tu directorio de trabajo, usa `git add -p` para seleccionar solo los cambios relevantes para cada commit. ## Qué NO incluir en un commit Antes de confirmar, revisa que no estés incluyendo archivos que no deberían estar en el repositorio: - Archivos `.env` o con credenciales - Archivos binarios grandes o compilados - Carpetas como `node_modules/`, `vendor/`, `__pycache__/` - Archivos temporales o de IDE (`.idea/`, `.vscode/settings.json` personales) ## Flujo al hacer commit Cuando el usuario pida hacer un commit, sigue este orden: 1. Ejecuta `git status` para ver los archivos modificados y sin seguimiento 2. Ejecuta `git diff` (staged y unstaged) para entender los cambios 3. Ejecuta `git log --oneline -5` para ver el estilo de commits recientes del proyecto 4. Analiza los cambios y redacta un mensaje de commit que siga las convenciones anteriores 5. Haz staging solo de los archivos relevantes (evita `git add .` a ciegas) 6. Crea el commit con el mensaje bien formateado 7. Añade siempre al final: `Co-Authored-By: Claude Opus 4.6 ` Si los cambios incluyen múltiples temas distintos, propón dividirlos en varios commits separados.