CV Recruitment Assistant

# Comando de Claude: Commit Este comando te ayuda a crear commits bien formateados con mensajes de conventional commit y emojis. ## Uso Para crear un commit, simplemente escribe: ``` /commit ``` O con opciones: ``` /commit --no-verify ``` ## Lo que hace este comando 1. A menos que se especifique con `--no-verify`, ejecuta automáticamente verificaciones pre-commit: - `npm run lint:fix` para asegurar la calidad del código - `npm run type-check` para verificar que no haya errores de TypeScript 2. Verifica qué archivos están en staging con `git status` 3. Si 0 archivos están en staging, automáticamente añade todos los archivos modificados y nuevos con `git add` 4. Ejecuta `git diff` para entender qué cambios se están commitando 5. Analiza el diff para determinar si hay múltiples cambios lógicos distintos presentes 6. Si se detectan múltiples cambios distintos, sugiere dividir el commit en múltiples commits más pequeños 7. Para cada commit (o el commit único si no se divide), crea un mensaje de commit usando formato emoji conventional commit ## Mejores prácticas para commits - **Verificar antes de commitear**: Asegurar que el código esté lintado, compile correctamente, y la documentación esté actualizada - **Commits atómicos**: Cada commit debe contener cambios relacionados que sirvan un propósito único - **Dividir cambios grandes**: Si los cambios tocan múltiples preocupaciones, dividirlos en commits separados - **Formato conventional commit**: Usar el formato `<tipo>: <descripción>` donde tipo es uno de: - `feat`: Una nueva funcionalidad - `fix`: Una corrección de bug - `docs`: Cambios en documentación - `style`: Cambios de estilo de código (formato, etc) - `refactor`: Cambios de código que no arreglan bugs ni añaden funcionalidades - `perf`: Mejoras de rendimiento - `test`: Añadir o corregir tests - `chore`: Cambios al proceso de build, herramientas, etc. - **Tiempo presente, modo imperativo**: Escribir mensajes de commit como comandos (ej., "añadir funcionalidad" no "añadió funcionalidad") - **Primera línea concisa**: Mantener la primera línea bajo 72 caracteres - **Emoji**: Cada tipo de commit se empareja con un emoji apropiado: - ✨ `feat`: Nueva funcionalidad - 🐛 `fix`: Corrección de bug - 📝 `docs`: Documentación - 💄 `style`: Formato/estilo - ♻️ `refactor`: Refactorización de código - ⚡️ `perf`: Mejoras de rendimiento - ✅ `test`: Tests - 🔧 `chore`: Herramientas, configuración - 🚀 `ci`: Mejoras de CI/CD - 🗑️ `revert`: Revertir cambios - 🧪 `test`: Añadir un test que falla - 🚨 `fix`: Corregir advertencias de compilador/linter - 🔒️ `fix`: Corregir problemas de seguridad - 👥 `chore`: Añadir o actualizar colaboradores - 🚚 `refactor`: Mover o renombrar recursos - 🏗️ `refactor`: Hacer cambios arquitecturales - 🔀 `chore`: Fusionar ramas - 📦️ `chore`: Añadir o actualizar archivos compilados o paquetes - ➕ `chore`: Añadir una dependencia - ➖ `chore`: Remover una dependencia - 🌱 `chore`: Añadir o actualizar archivos semilla - 🧑‍💻 `chore`: Mejorar experiencia del desarrollador - 🧵 `feat`: Añadir o actualizar código relacionado con multithreading o concurrencia - 🔍️ `feat`: Mejorar SEO - 🏷️ `feat`: Añadir o actualizar tipos - 💬 `feat`: Añadir o actualizar texto y literales - 🌐 `feat`: Internacionalización y localización - 👔 `feat`: Añadir o actualizar lógica de negocio - 📱 `feat`: Trabajar en diseño responsivo - 🚸 `feat`: Mejorar experiencia de usuario / usabilidad - 🩹 `fix`: Corrección simple para un problema no crítico - 🥅 `fix`: Capturar errores - 👽️ `fix`: Actualizar código debido a cambios en API externa - 🔥 `fix`: Remover código o archivos - 🎨 `style`: Mejorar estructura/formato del código - 🚑️ `fix`: Hotfix crítico - 🎉 `chore`: Comenzar un proyecto - 🔖 `chore`: Tags de release/versión - 🚧 `wip`: Trabajo en progreso - 💚 `fix`: Corregir build de CI - 📌 `chore`: Fijar dependencias a versiones específicas - 👷 `ci`: Añadir o actualizar sistema de build CI - 📈 `feat`: Añadir o actualizar código de analíticas o tracking - ✏️ `fix`: Corregir errores tipográficos - ⏪️ `revert`: Revertir cambios - 📄 `chore`: Añadir o actualizar licencia - 💥 `feat`: Introducir cambios que rompen compatibilidad - 🍱 `assets`: Añadir o actualizar assets - ♿️ `feat`: Mejorar accesibilidad - 💡 `docs`: Añadir o actualizar comentarios en código fuente - 🗃️ `db`: Realizar cambios relacionados con base de datos - 🔊 `feat`: Añadir o actualizar logs - 🔇 `fix`: Remover logs - 🤡 `test`: Mockear cosas - 🥚 `feat`: Añadir o actualizar un easter egg - 🙈 `chore`: Añadir o actualizar archivo .gitignore - 📸 `test`: Añadir o actualizar snapshots - ⚗️ `experiment`: Realizar experimentos - 🚩 `feat`: Añadir, actualizar, o remover feature flags - 💫 `ui`: Añadir o actualizar animaciones y transiciones - ⚰️ `refactor`: Remover código muerto - 🦺 `feat`: Añadir o actualizar código relacionado con validación - ✈️ `feat`: Mejorar soporte offline ## Pautas para dividir commits Al analizar el diff, considera dividir commits basándote en estos criterios: 1. **Diferentes preocupaciones**: Cambios a partes no relacionadas del código base 2. **Diferentes tipos de cambios**: Mezclar funcionalidades, correcciones, refactorizaciones, etc. 3. **Patrones de archivos**: Cambios a diferentes tipos de archivos (ej., código fuente vs documentación) 4. **Agrupación lógica**: Cambios que serían más fáciles de entender o revisar por separado 5. **Tamaño**: Cambios muy grandes que serían más claros si se dividen ## Ejemplos Buenos mensajes de commit: - ✨ feat: añadir sistema de autenticación de usuarios - 🐛 fix: resolver memory leak en proceso de renderizado - 📝 docs: actualizar documentación de API con nuevos endpoints - ♻️ refactor: simplificar lógica de manejo de errores en parser - 🚨 fix: resolver advertencias de linter en archivos de componentes - 🧑‍💻 chore: mejorar proceso de configuración de herramientas de desarrollo - 👔 feat: implementar lógica de negocio para validación de transacciones - 🩹 fix: abordar inconsistencia menor de estilo en header - 🚑️ fix: parchear vulnerabilidad crítica de seguridad en flujo de auth - 🎨 style: reorganizar estructura de componentes para mejor legibilidad - 🔥 fix: remover código legacy deprecado - 🦺 feat: añadir validación de entrada para formulario de registro de usuario - 💚 fix: resolver tests fallidos en pipeline de CI - 📈 feat: implementar tracking de analíticas para engagement de usuario - 🔒️ fix: fortalecer requisitos de contraseña de autenticación - ♿️ feat: mejorar accesibilidad de formulario para lectores de pantalla Ejemplo de división de commits: - Primer commit: ✨ feat: añadir definiciones de tipo para nueva versión de solc - Segundo commit: 📝 docs: actualizar documentación para nuevas versiones de solc - Tercer commit: 🔧 chore: actualizar dependencias de package.json - Cuarto commit: 🏷️ feat: añadir definiciones de tipo para nuevos endpoints de API - Quinto commit: 🧵 feat: mejorar manejo de concurrencia en worker threads - Sexto commit: 🚨 fix: resolver problemas de linting en código nuevo - Séptimo commit: ✅ test: añadir tests unitarios para funcionalidades de nueva versión de solc - Octavo commit: 🔒️ fix: actualizar dependencias con vulnerabilidades de seguridad ## Opciones del comando - `--no-verify`: Omitir las verificaciones pre-commit (lint:fix, type-check) ## Notas importantes - Por defecto, las verificaciones pre-commit (`npm run lint:fix`, `npm run type-check`) se ejecutarán para asegurar la calidad del código - Si estas verificaciones fallan, se te preguntará si quieres proceder con el commit de todos modos o arreglar los problemas primero - Si archivos específicos ya están en staging, el comando solo commitará esos archivos - Si no hay archivos en staging, automáticamente pondrá en staging todos los archivos modificados y nuevos - El mensaje de commit se construirá basado en los cambios detectados - Antes de commitear, el comando revisará el diff para identificar si múltiples commits serían más apropiados - Si sugiere múltiples commits, te ayudará a hacer staging y commit de los cambios por separado - Siempre revisa el diff del commit para asegurar que el mensaje coincida con los cambios