BWBYB/agent-skills

Commit Git Mínimo

Objetivo

Crear uno o más commits atómicos para la tarea actual del agente. Cada mensaje de commit generado sigue Conventional Commits. Mantén las entregas ordinarias con poco contexto; reserva el análisis completo del diff para una solicitud explícita de modo completo.

Selección de Modo

• Usa el modo rápido por defecto.
• Usa el modo completo solo cuando el usuario diga full, pida escanear o analizar el diff completo, o pida explícitamente revisar cada cambio.
• No mejoras silenciosamente el modo rápido a modo completo. Si el modo rápido carece de suficiente información, pide un resumen de cambios o pide al usuario que elija el modo completo.

Modo Rápido

Usa primero el resumen explícito del agente sobre la tarea actual. Cuando sea necesario, inspecciona solo:

git status --short
git diff --stat

No leas el diff completo ni el historial. No adivines sobre cambios ausentes del resumen. Agrupa los cambios declarados en commits atómicos y genera sus mensajes. Si el usuario pide explícitamente hacer commit, muestra los archivos/mensajes planeados antes de modificar el índice o crear commits cuando el límite de archivos no esté claro.

Modo Completo

Lee los diffs completos relevantes del árbol de trabajo y del área de staging, inspecciona todos los archivos cambiados y lee la referencia de Conventional Commits. Verifica que no falten características, pruebas, documentación, configuración, archivos no relacionados, archivos sensibles, archivos generados y cambios lógicos independientes. Confirma que los archivos generados pertenezcan al control de versiones: mantén las salidas requeridas por el proyecto, como lockfiles o migraciones, y excluye artefactos de compilación y salidas locales. Divide características independientes, correcciones de errores, refactorizaciones y cambios solo de formato en commits atómicos; mantén los cambios juntos cuando estén estrechamente acoplados y no se puedan probar o revertir de forma independiente. Ejecuta las verificaciones relevantes para los archivos cambiados usando los comandos existentes del proyecto. No ejecutes la suite completa de pruebas, lint y verificación de tipos por defecto; reutiliza las verificaciones ya ejecutadas durante la tarea y amplía la verificación solo cuando se solicite o sea necesario por los cambios. No inspecciones el historial a menos que se solicite explícitamente.

Antes de git add o git commit, preserva los cambios del usuario que están fuera de la tarea actual. Ejecuta esas mutaciones solo cuando el usuario pida explícitamente hacer commit. Nunca hagas push como parte de esta habilidad.

Reglas de Commit

Usa esta forma:

<tipo>[ámbito opcional]: <descripción>

[cuerpo opcional]

[pie(s) opcional(es)]

• Usa feat para una nueva funcionalidad y fix para una corrección de errores.
• Prefiere los tipos del proyecto docs, style, refactor, perf, test, build, ci, chore y revert cuando describan con precisión el cambio.
• Usa un ámbito nominal entre paréntesis solo cuando añada contexto útil.
• Marca los cambios disruptivos con ! antes de los dos puntos o con un pie BREAKING CHANGE: en mayúsculas.
• Mantén la descripción concisa, en presente, imperativa y preferiblemente de menos de 72 caracteres.
• Un commit representa un cambio lógico. Divide características independientes, correcciones, pruebas, documentación y refactorizaciones siempre que sea posible.
• fix corresponde a SemVer PATCH, feat a MINOR, y cualquier cambio disruptivo a MAJOR; no modifiques archivos de versión a menos que se solicite por separado.

Seguridad y Confirmación

• Nunca uses git add . por defecto; añade solo los archivos que pertenecen a la tarea actual.
• Nunca hagas commit de .env, credenciales, tokens, claves privadas u otros secretos.
• En modo completo, revisa el contenido del área de staging en busca de secretos y confirma que los archivos generados o de compilación sean esperados por el proyecto antes de incluirlos.
• Nunca modifiques la configuración de Git, omitas hooks, hagas force-push o modifiques un commit existente a menos que el usuario lo solicite explícitamente.
• No mezcles cambios preexistentes del usuario con los cambios del agente.
• Detente y pregunta cuando el límite de la tarea, la propiedad del archivo, la división lógica o el estado de archivos sensibles no estén claros.
• Crear un mensaje no es permiso para crear un commit; requiere una solicitud explícita de commit antes de git add o git commit.

Referencia

Lee references/conventional-commits.md en modo completo o cuando un tipo, pie, cambio disruptivo, reversión, SemVer o pregunta frecuente necesite un manejo detallado.