Skill personal para mensajes de commit con Conventional Commits

Hola, bienvenido. En la lección anterior creamos la skill project-qa y la dejamos preparada con git add, pero sin hacer el commit. En esta lección vamos a crear la skill que nos propone ese mensaje de commit, y es distinta de las 2 anteriores: en lugar de vivir en claude-tasks, vive en ~/.claude/skills/, tu carpeta personal, así que te sirve en cualquier repositorio que abras con Claude Code. Veremos cómo escribirla para que no dependa de ningún proyecto, cómo usarla para hacer el commit de project-qa y en qué sesiones no se carga una skill personal, que son la nube y las rutinas.

¿Por qué personal y no de proyecto? Porque escribir mensajes de commit con Conventional Commits es una forma de trabajar que te llevas a cada repositorio, y no depende de Laravel, de Sail ni de claude-tasks. Si la metieras en .claude/skills/ de cada proyecto, tendrías que copiarla en todos y mantener todas las copias. En ~/.claude/skills/ la escribes una vez y está disponible en todos los proyectos de tu máquina. La contrapartida es que solo la tienes tú: tus compañeros no la reciben con el repositorio, y hay entornos donde tampoco la vas a tener tú, como veremos al final.

La documentación resume así las 2 ubicaciones que vamos a comparar: una skill personal se carga en todos tus proyectos en esta máquina, pero no en Cowork ni en las sesiones en la nube, y una skill de proyecto se carga en las sesiones de ese repositorio, y en las de tu equipo si la subes a Git. Con eso ya tienes el criterio: lo que depende del proyecto va al proyecto, y lo que es tuyo y genérico va a tu carpeta personal.

Para seguir la lección necesitas claude-tasks con la skill project-qa preparada con git add, como la dejamos en la lección anterior, y una sesión de Claude Code abierta en la raíz del proyecto. La skill vive fuera del proyecto, así que no vamos a añadir ningún archivo a claude-tasks.

Conventional Commits es una especificación para dar estructura a los mensajes de commit, de forma que el historial se entienda de un vistazo y las herramientas puedan leerlo, por ejemplo para generar un changelog o decidir la siguiente versión. La versión actual es la 1.0.0, y el formato es este:

La especificación solo da significado a 2 tipos: feat, cuando el commit añade una funcionalidad, y fix, cuando corrige un fallo. Un cambio que rompe la compatibilidad se marca con una exclamación detrás del tipo o del scope, como en feat!:, o con un pie BREAKING CHANGE:. Se admiten más tipos, y la propia especificación cita los que recomienda la configuración convencional de commitlint: build, chore, ci, docs, style, refactor, perf y test. El scope es opcional y va entre paréntesis, como en feat(parser):.

Es lo que llevamos usando en todo el curso, con mensajes como feat: add Task model with completed scope o docs: add review-diff skill. Tienes la especificación completa en conventionalcommits.org↗ (se abre en una pestaña nueva), y si quieres ver cómo encaja en el flujo de trabajo de un equipo, junto con ramas, rebase y el resto de Git desde la terminal, lo tienes en el curso Git para Profesionales↗ (se abre en una pestaña nueva).