Marcussyl/cursor-skills

Commit por lotes

Divide el trabajo no commiteado en commits lógicos. Cada commit debe ser revisable por sí mismo e incluir todos los archivos necesarios para que ese fragmento tenga sentido.

Seguridad (siempre)

• Nunca actualices la configuración de Git.
• Nunca fuerces un push, un hard reset u otras operaciones destructivas de Git a menos que el usuario lo pida explícitamente.
• Nunca te saltes los hooks (--no-verify, etc.) a menos que el usuario lo pida explícitamente.
• Nunca incluyas secretos (.env, credenciales, claves) en el staging. Advierte y exclúyelos.
• Nunca uses git commit --amend a menos que se cumplan completamente las reglas del usuario para enmendar.
• Si un hook de commit falla, soluciona el problema y crea un nuevo commit; no enmiendes un commit fallido.
• No agregues Co-authored-by: Cursor a los mensajes de commit.

1. Inspeccionar

Ejecutar en paralelo cuando sea posible:

• git status
• git diff y git diff --staged
• git log -5 --oneline para el estilo de los mensajes
• git remote -v y seguimiento de ramas (git status -sb)

Si no hay nada que commitar, detente e indícalo.

2. Planificar lotes

Agrupa los cambios por propósito, no solo por tipo de archivo. Ejemplos:

• Una característica o comportamiento orientado al usuario + sus pruebas y documentación
• Una corrección de error + solo los archivos que la solucionan
• Refactorización independiente sin mezclar características no relacionadas
• Tarea o herramienta limitada a un área (dependencias, CI, configuración)

Reglas:

• No mezcles características no relacionadas en un solo commit.
• Incluye archivos complementarios en el mismo lote (por ejemplo, esquema + entidad + migración + sitios de llamada para un cambio).
• Si un archivo toca dos aspectos, prefiere el lote dominante o menciona la compensación antes de commitear.
• Enumera los lotes en orden: primero los fundamentos (tipos compartidos, configuración), luego las características, y finalmente solo documentación si depende de commits anteriores.

Muestra al usuario un plan breve: número de lote, archivos o rutas, y el asunto propuesto del commit convencional. Luego continúa a menos que se oponga.

3. Commitear cada lote

Para cada lote, secuencialmente:

1. Haz staging solo de ese lote (git add rutas específicas; evita git add -A a menos que todo el árbol sea un solo lote).
2. Vuelve a verificar con git diff --staged que no se haya colado nada no relacionado.
3. Escribe un asunto de Commit Convencional (feat, fix, chore, docs, refactor, test, etc.) centrado en el por qué.
4. Si el nombre de la rama contiene un ID de incidencia, agrega #<id> al asunto (estilo GitLab).
5. Haz commit. En Windows PowerShell, usa git commit -m 'asunto' (o varios -m para un cuerpo corto). En bash, un HEREDOC para el mensaje está bien.
6. Repite hasta que el árbol de trabajo esté limpio para los cambios previstos.

4. Subir a GitHub (o remoto)

Después de todos los lotes:

• Si origin (o el remoto nombrado por el usuario) existe y la rama debe publicarse, ejecuta git push -u origin HEAD cuando falte el upstream, de lo contrario git push.
• Nunca fuerces el push a main o master.
• Si se rechaza el push, informa del error y sugiere hacer pull/rebase; no fuerces a menos que el usuario lo solicite explícitamente.
• Si no hay remoto, indica que los commits son solo locales y pregunta si se debe agregar un remoto.

5. Informar

Resume:

• Cada hash de commit y su asunto (el más reciente al final o en lista numerada).
• Resultado del push (URL o rama si está disponible).
• Cualquier cosa que se haya quedado sin staging a propósito (secretos, archivos solo locales).

Relación con commit-msg

commit-msg sugiere una línea a partir de archivos ya en staging y no hace commit. Esta habilidad planifica, hace staging, commitea en varios pasos y sube.