Hogar

Skill

Revisión de código

changelog

sakuro/dotfiles

Genera entradas en el registro de cambios a partir de las confirmaciones realizadas desde la última versión. Se utiliza cuando el usuario desea actualizar el archivo CHANGELOG.md, añadir entradas al registro de cambios o documentar los cambios.

...Expandir todo

Tiempo actualizado 29 de junio de 2026

# bash # documentation # code-review # git # changelog # release-management # Code ReviewGit & Version ControlDocumentation

Acerca de changelog

La función « changelog » automatiza el proceso de generación de entradas en changelog a partir de las confirmaciones de Git realizadas desde la última versión. Está diseñada para ayudar a los equipos de desarrollo a mantener un registro coherente y centrado en el usuario de los cambios en sus proyectos. Al analizar los mensajes de commit y distinguir entre cambios visibles para el usuario y cambios internos, esta skill garantiza que el archivo CHANGELOG.md refleje actualizaciones significativas y relevantes para los usuarios finales. Esto reduce el esfuerzo manual, evita que se pasen por alto cambios y garantiza que la documentación de la versión se mantenga precisa y actualizada.

La skill proporciona un flujo de trabajo estructurado para extraer información de las confirmaciones, clasificar los cambios y dar formato a las entradas siguiendo un estilo estandarizado. Entre sus características principales se incluyen la identificación de cambios orientados al usuario, como nuevas funcionalidades, correcciones de errores, mejoras de rendimiento, elementos obsoletos y actualizaciones de seguridad, al tiempo que se excluyen los cambios puramente internos, como la refactorización, las pruebas o las modificaciones de CI/CD. Extrae automáticamente las referencias a incidencias de los mensajes de confirmación y organiza las entradas en categorías predefinidas (Añadido, Modificado, Corregido, Eliminado, Obsoleto, Seguridad). Además, determina la sección adecuada del « changelog » en función de la rama actual, admitiendo tanto versiones publicadas como una sección «Sin publicar». La skill utiliza comandos de Bash y la herramienta Edit para leer y actualizar el « changelog » sin problemas.

Esta skill es ideal para desarrolladores, gestores de lanzamientos y equipos que mantienen proyectos de software de código abierto o internos y que desean optimizar el mantenimiento del « changelog ». Resulta especialmente útil para proyectos con commits frecuentes o con múltiples colaboradores, ya que garantiza que todos los cambios relevantes para los usuarios queden documentados de forma coherente. Los usuarios se benefician de un ahorro de tiempo, una reducción de los errores y una « changelog » profesional y estructurada que comunica las actualizaciones con claridad a los usuarios finales, las partes interesadas y los colaboradores.

Preguntas frecuentes

¿Cómo se utiliza la skill « changelog »?

Empieza por ejecutar la skill en el repositorio de tu proyecto. Detectará automáticamente las confirmaciones realizadas desde la última versión, clasificará los cambios que afectan a los usuarios, extraerá las referencias a incidencias y actualizará el archivo « CHANGELOG.md» en la sección correspondiente (sin publicar o versión publicada).

¿Qué tipos de cambios se incluyen en el « changelog »?

La skill incluye cambios visibles para el usuario, como nuevas funcionalidades, correcciones de errores, mejoras de rendimiento, cambios incompatibles, elementos obsoletos y correcciones de seguridad. Se excluyen los cambios internos, como la refactorización, las pruebas, la integración continua y la entrega continua (CI/CD) o las actualizaciones del estilo de código, a menos que afecten al comportamiento visible para el usuario.

¿Puede gestionar repositorios sin etiquetas de lanzamiento anteriores?

Sí, si no existe ninguna etiqueta de lanzamiento previa, la skill analiza las confirmaciones más recientes (hasta 50) para generar entradas de « changelog » y las coloca en la sección «Sin publicar».

¿Fusiona automáticamente las nuevas entradas con el contenido existente de « changelog »?

Sí, la skill lee el archivo .md actual de « CHANGELOG », crea la sección de destino si no existe y fusiona las nuevas entradas evitando los duplicados.

¿Son obligatorias las referencias a incidencias en los mensajes de commit?

No, las referencias a incidencias son opcionales. Cuando están presentes, se incluyen en la entrada con el formato «(#123)». Las referencias múltiples se fusionan como «(#123, #124)».

Ver en GitHub

Changelog Generation Skill

Analyzes commits since the last release and adds user-facing changes to CHANGELOG.md.

Instructions

IMPORTANT: When using this skill, announce to the user: "Using changelog skill to generate changelog entries."

1. Get Last Release Tag

# Get the most recent release tagLAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")if [ -z "$LAST_TAG" ]; then  echo "No previous release tag found. Will analyze all commits."fi

2. Get Commits Since Last Release

# If tag existsgit log --format="%H %s" "$LAST_TAG"..HEAD# If no tag, get recent commitsgit log --format="%H %s" -50

3. Analyze Each Commit

For each commit, determine if it has user-facing impact:

Include (user-facing):

New features (:sparkles:)
Bug fixes (:bug:)
Performance improvements (:zap:)
Breaking changes (:boom:)
Deprecations
Security fixes (:lock:)

Exclude (internal):

Refactoring (:recycle:) - unless it changes behavior
Tests (:white_check_mark:)
CI/CD changes (:construction_worker:)
Documentation (:memo:) - unless user-facing docs
Code style (:art:)
Merge commits

4. Extract Issue References

Look for issue references in commit messages:

#123
Fixes #123
Closes #123
Related to #123

5. Categorize Changes

Group entries by category:

### Added- New features### Changed- Changes to existing functionality### Fixed- Bug fixes### Removed- Removed features### Deprecated- Soon-to-be removed features### Security- Security fixes

6. Format Entries

Each entry should:

Start with imperative verb (Add, Fix, Change, Remove)
Be concise (one line)
Include issue reference at end if available

Examples:

- Add list formatting support (#42)- Fix memory leak in data provider (#88)- Change default locale to en-US

7. Determine Target Section

# Get current branchBRANCH=$(git branch --show-current)# Determine target sectionif [[ "$BRANCH" =~ ^release-v([0-9]+\.[0-9]+\.[0-9]+)$ ]]; then  # On release branch → target is that version  TARGET_SECTION="[${BASH_REMATCH[1]}]"else  # Not on release branch → target is Unreleased  TARGET_SECTION="[Unreleased]"fi

8. Update CHANGELOG.md

If target section doesn't exist, create it
Add/merge entries under the target section

Creating new section if needed:

For [Unreleased]: Add after the header, before first version section
For version [X.Y.Z]: Add after [Unreleased], before previous versions

Example structure:

## [Unreleased]## [0.7.0] - 2024-01-15### Added- New feature description (#123)## [0.6.0] - 2024-01-01...

Use the Edit tool to update CHANGELOG.md.

Workflow

Get last release tag
List commits since that tag
For each commit:
- Read commit message
- Determine if user-facing
- Extract issue references
- Categorize (Added/Changed/Fixed/etc.)
Determine target section:
- On release-vX.Y.Z branch → [X.Y.Z]
- Otherwise → [Unreleased]
Read current CHANGELOG.md
Create target section if it doesn't exist
Merge new entries with existing content in target section
Update CHANGELOG.md using Edit tool

Guidelines

Entry Writing

Use imperative mood: "Add" not "Added" or "Adds"
Be specific but concise
Focus on user impact, not implementation details
One logical change per entry

Issue References

Always include if available
Format: (#123) at end of line
Multiple issues: (#123, #124)

Avoiding Duplicates

Check existing [Unreleased] entries before adding
Merge or update if similar entry exists

Example Output

## [Unreleased]### Added- Implement DecimalFormatter for number formatting (#42)- Add locale fallback support### Changed- Update default collation strength to tertiary### Fixed- Fix crash when parsing invalid locale string (#55)- Resolve memory leak in DataProvider (#58)