convenciones-git
Convenciones de ramas y mensajes de commit de este proyecto. Usala siempre que vayas a crear una rama, escribir un mensaje de commit o commitear cambios.
SKILL.md.claude/skills/convenciones-git/SKILL.md
GitHubConvenciones de Git
Quién commitea
El trabajo con ticket lo commitea el delivery-specialist, que verifica el
árbol contra el ticket antes de escribir el mensaje. Los demás especialistas
dejan sus archivos en el árbol de trabajo y dicen qué cambiaron.
La sesión principal y el arquitecto commitean por su cuenta: documentación, ADR y configuración están fuera del circuito de tickets a propósito.
Antes de commitear
- Revisá
git statusygit diffcompletos. No commitees a ciegas. - Verificá que no entren secretos, claves, correos ni rutas absolutas.
- Confirmá que los cambios corresponden a una sola intención. Si hay dos, son dos commits.
Recién con esto en orden, escribí el mensaje.
Tipos
Toda rama y todo commit se clasifican con uno de estos once tipos:
| Tipo | Cuándo |
|---|---|
feat |
Funcionalidad nueva |
fix |
Corrección de un error |
refactor |
Cambio interno sin alterar el comportamiento |
style |
Interfaz, estilos, experiencia de uso |
docs |
Documentación |
chore |
Mantenimiento que no encaja en los demás (dependencias, configuración) |
test |
Pruebas |
ci |
Integración continua |
build |
Sistema de build o dependencias externas |
perf |
Mejoras de rendimiento |
revert |
Revertir un commit anterior |
Siempre en minúscula, tanto en la rama como en el commit.
Los tipos también titulan los issues
Un ticket y el commit que lo cierra describen el mismo trabajo, así que el título
de un issue usa la misma convención que el título del commit (ver más abajo):
tipo(alcance): mensaje breve. Ver docs/agents/issue-tracker.md.
Nombre de rama
<tipo>/<número-de-ticket>-<descripción-en-kebab-case>
El número es el del ticket que abre la rebanada — si la rebanada cubre varios tickets, va solo el primero; los demás quedan referenciados en los commits, no en el nombre de rama. La descripción va en inglés, en minúsculas, con guiones, y nombra el alcance del trabajo, no la tarea puntual.
Ejemplos: feat/29-curated-content-import · fix/31-catalog-search ·
docs/40-architecture-adr · style/26-hero-card
Las ramas que ya existen con el formato viejo (sin número, o con descripción en
español, o con bugfix/design como tipo) no se renombran: la regla rige
desde acá en adelante, para las ramas nuevas.
Mensaje de commit
Título:
tipo(alcance): descripción corta en minúscula
- El tipo es uno de la tabla de arriba, en minúscula, sin corchetes.
- El alcance va entre paréntesis y nombra el módulo o área que toca el commit
(
catalogo,moderacion,aprendizaje,progreso,identidad,db,web,contenido,config…). Si el commit no cae en un área puntual, se omite el alcance:tipo: descripción. - La descripción va en minúscula y dice qué se hizo, sin punto final.
Descripción: dice exclusivamente dos cosas, en este orden, en español y en ítems.
- Listado de las cosas que cambiaron.
- Razones por las que estas cosas cambiaron.
Nada más: ni instrucciones de uso, ni planes a futuro, ni comentarios.
Sin sujeto. Cada ítem describe el cambio, no a quien lo hizo: nunca "hice", "agregué" ni "el agente implementó". Se redacta en impersonal o pasiva refleja —"se estableció", "se agregó", "se corrigió", "quedó resuelto"—, porque el commit documenta el estado del árbol, no la autoría de una sesión.
Referencia al ticket: si el commit corresponde a un ticket, cerrá el mensaje con una última línea que lo referencie.
Ticket: #12
Es una referencia, no un cierre. No uses Closes #12 ni Fixes #12: esas
palabras hacen que GitHub cierre el issue solo al publicar, y en este proyecto
el cierre es explícito y tiene una condición —el PR que trae el commit tiene
que estar mergeado en development—.
Ejemplo
Rama: feat/29-curated-content-import
feat(contenido): importación de contenido desde archivos
Cambios:
- Se agregó el script de importación que lee `contenido/` y escribe en la
base.
- Se validó cada ficha contra el descriptor Zod de su tipo.
- Se agregó su comando en `package.json`.
Razones:
- El contenido curado vive en archivos versionados (ADR 0004) y hacía falta
el paso que lo lleva a la base, que es lo que sirve la aplicación.
- Validar en la importación evita que entre contenido que no cumple el
esquema del tipo.
Ticket: #12