Linter de Conventional Commit

Pega un mensaje de commit y mira si cumple con la especificación Conventional Commits v1.0.0. Tipo, scope, longitud y forma del subject, body, footers y el marcador BREAKING CHANGE — todo se valida en vivo. Las reglas son configurables; el botón Reformatear reescribe la entrada a su forma canónica. 100% del lado del cliente, sin subir nada.

—
Reglas — comprueba la entrada en vivo
Veredicto
Inactivo Escribe un mensaje de commit arriba.
Hallazgos
—
  • Aún no hay hallazgos.
Analizado 
La estructura analizada aparece aquí.
Plantillas — muestras de un clic para las formas más habituales
Cómo funcionan las reglas
  • Encabezado debe coincidir con <tipo>(<scope>)?!: <descripción>. El ! es opcional y marca un cambio incompatible.
  • Tipo debe ser uno de feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. La comprobación es insensible a mayúsculas pero la convención es minúsculas.
  • Scope es un sustantivo entre paréntesis, p. ej. feat(api):. Activa Requerir scope para hacerlo obligatorio.
  • Subject es el resumen corto tras los dos puntos. Mantenlo ≤ 72 caracteres (el límite por defecto), en minúsculas, sin punto final, en modo imperativo (añade, no añadido).
  • Body explica el porqué. Corta las líneas a ~100 caracteres. Sepáralo del encabezado con una línea en blanco. Activa Requerir body para hacerlo obligatorio.
  • Footers siguen la convención de trailers de Git (token: valor o token #valor). Usa BREAKING CHANGE: … (o ! en el encabezado) para señalar cambios incompatibles.
  • Reformatear reescribe la entrada a la forma canónica: tipo en minúsculas, footer BREAKING CHANGE primero, después el resto en el orden de entrada.
  • Todo se ejecuta en local. Nada sale del navegador.