# Smart Commit

> Analiza los cambios staged y unstaged para recomendar si crear un solo commit o varios commits separados, y genera mensajes de commit apropiados. Usar cuando el usuario pida sugerencias de commit, quiera hacer commit, o pregunte como organizar sus commits.

- Skill: `phoebe-wd/smart-commit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add phoebe-wd/smart-commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/phoebe-wd/smart-commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Phoebe-WD (https://skillmd.com/u/phoebe-wd)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/phoebe-wd/smart-commit

---


Al analizar cambios para recomendar commits:

1. Ejecutar `git status` para ver todos los archivos modificados, agregados y eliminados
2. Ejecutar `git diff` para ver cambios unstaged y `git diff --cached` para ver cambios staged
3. Para cada archivo modificado, ejecutar `git diff <archivo>` para entender que cambio
4. Ejecutar `git log --oneline -5` para ver el estilo de commits recientes y seguir la misma convención

## Criterios de analisis

Evaluar los cambios y clasificarlos en grupos lógicos según:

- **Propósito**: Todos los cambios sirven al mismo objetivo? (bug fix, feature, refactor, docs, config, etc.)
- **Alcance**: Los cambios están en archivos/módulos relacionados o dispersos en áreas no relacionadas?
- **Dependencias**: Un cambio no tendría sentido sin otro? Esos van juntos.
- **Reversibilidad**: Cada grupo podría revertirse independientemente sin romper el proyecto?

## Reglas de decisión

### Recomendar UN SOLO commit cuando:

- Todos los cambios sirven al mismo propósito (ej: todos son parte de un bug fix o una feature)
- Los cambios son interdependientes y revertir uno sin los otros rompería cosas
- El diff total es pequeño (menos de ~50 líneas entre todos los archivos)

### Recomendar MULTIPLES commits cuando:

- Los cambios sirven a propósitos diferentes (ej: un bug fix + un refactor + una feature nueva)
- Los archivos pertenecen a módulos o áreas no relacionadas del codebase
- Algunos cambios son cosméticos (formato, typos) mientras otros son funcionales
- Hay cambios de config/dependencias mezclados con cambios de lógica

## Formato de salida

Presentar la recomendación de la siguiente manera. Los mensajes de commit **SIEMPRE** deben estar en inglés.

### Si es un solo commit:

```
Recomendación: 1 commit

Archivos:
- lista de todos los archivos

Mensaje: <mensaje de commit en inglés siguiendo la convención del proyecto>
```

### Si son multiples commits:

```
Recomendación: N commits

Commit 1:
  Archivos:
  - archivo1
  - archivo2
  Mensaje: <mensaje de commit en inglés siguiendo la convención del proyecto>

Commit 2:
  Archivos:
  - archivo3
  Mensaje: <mensaje de commit en inglés siguiendo la convención del proyecto>

...
```

## Guias para mensajes de commit

### Las cuatro reglas de un buen commit

1. Limitar la línea del subject a 50 caracteres
2. Capitalizar la línea del subject
3. No terminar la línea del subject con punto
4. Usar modo imperativo en la línea del subject

### Verbos iniciales obligatorios

Cada mensaje de commit DEBE comenzar con uno de estos verbos en modo imperativo. Seleccionar el verbo según el tipo de cambio:

| Verbo        | Uso                                                                    |
| ------------ | ---------------------------------------------------------------------- |
| **Feat**     | Crear una capacidad: feature, test, dependencia                        |
| **Fix**      | Corregir un issue: bug, typo, accidente, error                         |
| **Docs**     | Cambio que SOLO es en documentación: archivos de ayuda                 |
| **Refactor** | Cambio que SOLO es un refactoring de código                            |
| **Perf**     | Cambio que SOLO es de performance: acelerar código                     |
| **Test**     | Cambio que SOLO es de pruebas: agregar, modificar o eliminar tests     |
| **Style**    | Cambio que SOLO es de estilo: formato, indentación, espacios en blanco |

### Formato del mensaje

```
<Verbo> <descripción corta en imperativo>

[Body opcional explicando qué y por qué]
```

**Ejemplos:**

- `Feat: user authentication with JWT tokens`
- `Fix: null pointer exception in payment service`
- `Docs: update README with new API endpoints`
- `Refactor: database connection pool management`
- `Perf: optimize image loading with lazy loading`
- `Test: add unit tests for user service`
- `Style: reformat code with Prettier`

### Reglas adicionales

- Revisar `git log --oneline -5` para contexto, pero SIEMPRE usar la convención de verbos definida arriba
- Los mensajes **SIEMPRE** en inglés, incluso si el usuario habla otro idioma
- Agregar body solo si el cambio es complejo y necesita explicación del qué y por qué

## Ejecucion

Después de presentar la recomendación, NO ejecutar los commits. El usuario los hará manualmente. Solo presentar la recomendación con los archivos y mensajes sugeridos, y los comandos git que el usuario necesitaría ejecutar para cada commit.

**IMPORTANTE**: No agregar `Co-Authored-By` ni ningún otro trailer a los mensajes de commit generados por esta skill.