Help us improve
Share bugs, ideas, or general feedback.
From alfred-dev
Generates changelog entries following Keep a Changelog format by reviewing Git history, classifying changes into Added, Changed, Deprecated, Removed, Fixed, Security categories with user-focused wording.
npx claudepluginhub 686f6c61/alfred-dev --plugin alfred-devHow this skill is triggered — by the user, by Claude, or both
Slash command
/alfred-dev:changelogThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Este skill genera entradas de changelog siguiendo el formato Keep a Changelog (keepachangelog.com). El changelog es el documento que los usuarios consultan para saber qué ha cambiado entre versiones. Está escrito para personas, no para máquinas: el lenguaje debe ser claro y orientado al impacto para el usuario, no a los detalles internos de implementación.
Generates CHANGELOG.md files in Keep a Changelog format with templates for Added, Changed, Deprecated, Removed, Fixed, and Security sections. Includes guidelines and examples for version history.
Converts git logs, commit lists, or release notes into polished changelogs following Keep a Changelog conventions. Categorizes changes and adds migration notes.
Generates user-facing changelogs with impact notes and support guidance from git history using Keep a Changelog format. Use for drafting release notes from commits.
Share bugs, ideas, or general feedback.
Este skill genera entradas de changelog siguiendo el formato Keep a Changelog (keepachangelog.com). El changelog es el documento que los usuarios consultan para saber qué ha cambiado entre versiones. Está escrito para personas, no para máquinas: el lenguaje debe ser claro y orientado al impacto para el usuario, no a los detalles internos de implementación.
Un buen changelog responde a la pregunta "qué ha cambiado que me afecta" sin requerir que el lector entienda el código.
Nota: este skill genera entradas de changelog individuales. Para el proceso completo de publicación de una release (versionado, changelog, notas, publicación), usar el protocolo release-planning.
Identificar los cambios a documentar. Revisar el historial de Git desde la última versión publicada:
Filtrar los cambios internos (refactoring, actualización de CI) que no afectan al usuario, a menos que sean relevantes (como mejoras de rendimiento).
Clasificar cada cambio en su categoría. Keep a Changelog define seis categorías:
| Categoría | Descripción | Ejemplo |
|---|---|---|
| Added | Funcionalidad nueva | "Soporte para autenticación con Google" |
| Changed | Cambio en funcionalidad existente | "El límite de subida de archivos pasa de 5MB a 20MB" |
| Deprecated | Funcionalidad que se eliminará en una versión futura | "El endpoint /v1/users se sustituirá por /v2/users en la versión 3.0" |
| Removed | Funcionalidad eliminada | "Se elimina el soporte para IE11" |
| Fixed | Corrección de errores | "Corregido error que impedía guardar formularios con campos vacíos" |
| Security | Corrección de vulnerabilidades | "Actualizada dependencia X para corregir CVE-YYYY-NNNN" |
Redactar cada entrada. Reglas de redacción:
Formato del encabezado de versión:
## [1.2.0] - 2024-03-15
### Added
- Soporte para exportar datos en formato CSV (#42)
- Nuevo filtro de búsqueda por fecha (#38)
### Fixed
- Corregido error al paginar resultados con más de 1000 registros (#45)
### Security
- Actualizada dependencia lodash a 4.17.21 para corregir CVE-2021-23337 (#47)
Mantener la sección [Unreleased]. Los cambios que aún no forman parte de una versión se agrupan bajo [Unreleased] en la parte superior del changelog. Al publicar una nueva versión, estos cambios se mueven bajo el encabezado de la nueva versión.
Verificar enlaces. Si el changelog incluye enlaces a issues o PRs, verificar que los enlaces son correctos y accesibles.
Ubicación del fichero. El changelog se guarda como CHANGELOG.md en la raíz del proyecto, siguiendo la convención estándar.