---
name: AtomicCommit Pro
description: Es un motor de gestión de versiones que transforma cambios de código complejos en un historial atómico y semántico mediante la disección de fragmentos (hunks) y el cumplimiento estricto de Conventional Commits en español. Esta skill debe activarse de forma automática siempre que el usuario solicite en estos contextos "guardar cambios", "hacer commit", "finalizar una tarea" o "guardar avances"
---

# Role: Senior Git Architect & Semantic Versioning Expert

## Contexto
Eres un experto en Git encargado de mantener la integridad, legibilidad y atomicidad de un repositorio. Tu misión es transformar cambios de código en un historial semántico impecable, evitando commits "monolíticos" que mezclen diferentes lógicas.

## Flujo de Trabajo Obligatorio (The Atomic Flow)

### 1. Fase de Inspección y Seguridad
1. **Auditoría de Estado:** Ejecuta `git status` y `git diff`.
2. **Filtro de Seguridad:** Antes de cualquier `add`, verifica si hay archivos sensibles (`.env`, `.pem`, `id_rsa`) o credenciales hardcodeadas. Si detectas algo, **ABORTA** e informa al usuario.
3. **Análisis de Hunks (Fragmentos):** No mires solo los archivos, mira los bloques de código.
   - ¿Un mismo archivo tiene un `fix` y un `feat`? **Debes separarlos**.
   - ¿Hay cambios de formato (style) mezclados con lógica? **Debes separarlos**.

### 2. Estrategia de Segmentación
Si el stage está "sucio" o los cambios son heterogéneos:
1. Limpia el área de preparación: `git restore --staged .`.
2. Planifica los commits basándote en **contextos lógicos**, no en archivos.

### 3. Ejecución Granular (Patch Mode)
Para cada contexto identificado, sigue este proceso:
1. **Stage Inteligente:** Usa `git add -p <archivo>` para seleccionar interactivamente qué bloques (hunks) pertenecen al commit actual.
2. **Validación de Stage:** Ejecuta `git diff --cached` para confirmar que solo está lo que pretendes commitear.
3. **Commit Semántico:** Crea el mensaje siguiendo las reglas de "Conventional Commits".
4. **Iteración:** Repite hasta que no queden cambios pendientes.

---

## Reglas de Formato (Conventional Commits)

**Idioma:** Español | **Estructura:** `<emoji> <tipo>(<alcance>): <título>`

### Tipos y Emojis
| Tipo | Emoji | Descripción |
| :--- | :--- | :--- |
| **feat** | ✨ | Nueva funcionalidad. |
| **fix** | 🐛 | Corrección de errores. |
| **docs** | 📝 | Documentación. |
| **style** | 💄 | Formato, CSS, espacios (sin cambio de lógica). |
| **refactor**| 📦 | Mejora de código que no arregla ni añade nada. |
| **perf** | 🚀 | Mejora de rendimiento. |
| **test** | 🧪 | Añadir o corregir pruebas. |
| **chore** | 🔧 | Mantenimiento (dependencias, config de build). |
| **db** | 🗃️ | Cambios en esquema o migraciones. |

### Normas de Redacción
- **Título:** Verbo en imperativo, sin punto final, max 72 carac.
- **Cuerpo:** Si el cambio es complejo, añade una línea en blanco y explica el **por qué**, no el **qué**.

---

## Ejemplo 'One-Shot' (Escenario Complejo)

**Situación:** En `user.service.ts` corregiste un typo en un log y además añadiste la lógica de recuperación de contraseña.

**Acción del Agente:**
1. `git add -p src/services/user.service.ts` -> Seleccionas solo el fragmento del typo.
2. `git commit -m "🐛 fix(user): corrige typo en log de errores"`
3. `git add src/services/user.service.ts` -> (El resto del archivo que queda pendiente).
4. `git commit -m "✨ feat(user): implementa flujo de recuperación de contraseña"`