Gentleman-Programming/gentle-ai-work-unit-commits

Cuándo usar

Carga esta skill al decidir qué incluir en cada commit o PR.

Úsala para:

• Dividir una funcionalidad en trabajo revisable.
• Preparar commits antes de abrir un PR.
• Convertir un cambio grande en PRs encadenados o apilados.
• Mantener la carga cognitiva del revisor saludable.
• Aplicar tareas SDD sin producir accidentalmente un PR de más de 400 líneas modificadas.

Reglas críticas

Regla	Requisito
Commit por unidad de trabajo	Un commit representa una unidad entregable de comportamiento, corrección, migración o documentación.
No commitear por tipo de archivo	Evitar modelos, luego servicios, luego pruebas si ninguno funciona por sí solo.
Mantener pruebas con el código	Las pruebas pertenecen al mismo commit que el comportamiento que verifican.
Mantener documentación con el cambio visible para el usuario	La documentación pertenece con la funcionalidad o flujo de trabajo que explica.
Contar una historia	Un revisor debe entender por qué existe cada commit a partir de su diff y mensaje.
Listo para futuro PR	Cada commit debería ser un candidato para un PR encadenado cuando el cambio crezca.
Guardia de carga SDD	Si las tareas SDD pronostican un cambio de >400 líneas, agrupa los commits en rodajas de PRs encadenados antes de la implementación.
El presupuesto no es para minimizar código	Nunca reduzcas un diff eliminando comentarios, líneas en blanco, documentación o pruebas, ni comprimiendo código, para cumplir con el presupuesto de revisión (400 por defecto, o el review_budget_lines de la sesión). Divide por unidad de trabajo o reporta el exceso.

Lista de verificación de unidad de trabajo

Antes de commitear, confirma:

• El commit tiene un propósito claro.
• El repositorio sigue teniendo sentido después de aplicar solo este commit.
• Las pruebas o la documentación para esta unidad están incluidas cuando corresponda.
• La reversión es razonable sin deshacer trabajo no relacionado.
• El mensaje del commit explica el resultado, no la lista de archivos.

Ejemplos de división

División débil	Mejor división por unidad de trabajo
añadir modelos	feat(auth): añadir modelo de dominio de validación de tokens y pruebas
añadir servicios	feat(auth): conectar validación de tokens en el flujo de inicio de sesión
añadir pruebas	Pruebas incluidas con cada commit de comportamiento
actualizar docs	Documentación incluida con el cambio visible para el usuario que explica

Relación con PR

Usa los commits por unidad de trabajo como base para PRs encadenados:

1. Construye la unidad de trabajo independiente más pequeña.
2. Incluye la verificación de esa unidad.
3. Haz commit con un mensaje de Conventional Commit.
4. Si el PR se acerca a las 400 líneas modificadas, promociona los commits o grupos de commits a PRs encadenados.

Relación con SDD

Cuando sdd-tasks produce un Pronóstico de Carga de Revisión:

• Bajo riesgo: mantén los commits por unidad de trabajo dentro de un solo PR.
• Riesgo medio: haz commit por unidad de trabajo y monitorea las líneas modificadas antes de crear el PR.
• Alto riesgo: sigue la delivery_strategy de SDD — pregunta con ask-on-risk, divide automáticamente con auto-chain, requiere size:exception en single-pr que exceda el presupuesto, o registra un size:exception aceptado en exception-ok.
• La división está limitada: después de una pasada honesta de división, si ninguna división cohesiva por unidad de trabajo cumple con el presupuesto, detente e informa el recuento honesto más pequeño con una recomendación de size:exception. No iteres reduciendo el código para alcanzar el número.

Cada unidad de trabajo SDD debe mapearse limpiamente a un commit o PR con:

• estado inicial claro,
• estado final claro,
• verificación en la misma unidad,
• reversión que no elimine trabajo no relacionado.

Comandos

# Revisa la historia antes de commitear
git diff --stat
git diff --cached --stat

# Revisa el estilo de commits recientes
git log --oneline -5