docs-changeloglisted

# Cómo se escribe el `CHANGELOG.md` en este proyecto Esta skill es **plana**: no forkea a `docs-manager`. El motor de documentación no tiene `Bash` a propósito (así no puede commitear), y generar el changelog exige leer el rango de commits con `git log`. El hilo principal sí puede, y además es quien conoce el rango de la feature. ## Cuándo En el **cierre** de la feature, después de `/speckit-converge` y con los commits ya hechos. Nunca a mano en mitad del desarrollo: las entradas se derivan de los commits, no al revés. ## Formato [Keep a Changelog](https://keepachangelog.com) 2.0.0. Bajo cada versión, solo las secciones que tengan contenido, en este orden: `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, `Security`. ## Procedimiento 1. **Obtén el rango.** Los commits de la feature, típicamente `git log dev..HEAD --no-merges`. Si la rama base no es `dev` o el rango no está claro, pregúntalo antes de generar nada. 2. **Mapea cada Conventional Commit a su sección**: | Prefijo del commit | Sección | |---|---| | `feat` | `Added` | | `fix` | `Fixed` | | `refactor`, `perf`, `style` | `Changed` (solo si el cambio es visible para quien usa el proyecto) | | `deprecate` o commit que marca algo como obsoleto | `Deprecated` | | commit que elimina una capacidad | `Removed` | | cambio en autenticación, secretos, dependencias vulnerables | `Security` | | `docs`, `test`, `chore`, `ci` | **no entran** en el changelog | 3. **Redacta para quien usa el