# Changelog

> Genera automáticamente un changelog a partir de commits de git, datos de sprint y documentos de diseño, produciendo versiones interna y para jugadores.

Fuente: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/changelog
Markdown: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/changelog.md

Repositorio: https://github.com/Donchitos/Claude-Code-Game-Studios
Autor: Donchitos
Licencia: MIT
Actualizado: hace 4 meses
Coste de contexto: 33 tok instalada, 1.5k tok al activarse, 1.5k tok con todos los archivos del bundle
Bundle: 1 archivo, 6 KB
Permisos que pide: read, glob, grep, bash, write

## Instalación

Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina.

```bash
# Claude Code
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill changelog --agent claude-code
# Cursor
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill changelog --agent cursor
# Codex
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill changelog --agent codex
# Gemini CLI
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill changelog --agent gemini
# Windsurf
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill changelog --agent windsurf
# Cline
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill changelog --agent cline
```

## Qué hace

- Genera un changelog interno técnico y una versión player-facing a partir de git log, sprints y documentos de diseño
- Categoriza cambios en New Features, Improvements, Bug Fixes, Balance, Known Issues y Miscellaneous
- Calcula métricas como commits totales, líneas cambiadas y commits sin referencia a tarea
- Ofrece escribir el resultado en docs/CHANGELOG.md, con opción de anexar o sobrescribir

## Cuándo usarla

- Necesitas generar un changelog para una versión o número de sprint concreto
- Quieres separar la comunicación técnica interna de la comunicación orientada a jugadores

## Cuándo no

- El repositorio no es un repositorio git válido (no hay .git inicializado)

## Qué la activa

- "/changelog v1.4.0"
- "Genera el changelog del sprint 12"
- "Crea el changelog interno y el de jugadores para la última release"

## Antes de instalar

- Requiere un repositorio git inicializado, con acceso opcional a production/sprints/ y design/gdd/ para contexto adicional.
- Necesita en el PATH: git
- runs shell commands
- writes to your files

## Archivos

- SKILL.md — 6 KB

## SKILL.md

Reproducido tal cual desde Donchitos/Claude-Code-Game-Studios bajo MIT. Esta sección es el documento original y está en inglés.

## Phase 1: Parse Arguments

Read the argument for the target version or sprint number. If a version is given, use the corresponding git tag. If a sprint number is given, use the sprint date range.

Verify the repository is initialized: run `git rev-parse --is-inside-work-tree` to confirm git is available. If not a git repo, inform the user and abort gracefully.

---

## Phase 2: Gather Change Data

Read the git log since the last tag or release:

```
git log --oneline [last-tag]..HEAD
```

If no tags exist, read the full log or a reasonable recent range (last 100 commits).

Read sprint reports from `production/sprints/` for the relevant period to understand planned work and context behind changes.

Read completed design documents from `design/gdd/` for any new features implemented during this period.

---

## Phase 3: Categorize Changes

Categorize every change into one of these categories:

- **New Features**: Entirely new gameplay systems, modes, or content
- **Improvements**: Enhancements to existing features, UX improvements, performance gains
- **Bug Fixes**: Corrections to broken behavior
- **Balance Changes**: Tuning of gameplay values, difficulty, economy
- **Known Issues**: Issues the team is aware of but have not yet resolved
- **Miscellaneous**: Changes that do not fit the above categories, or commits whose messages are too vague to classify confidently

For each commit, check whether the message contains a task ID or story reference
(e.g. `[STORY-123]`, `TR-`, `#NNN`, or similar). Count commits that lack any task reference
and include this count in the Phase 4 Metrics section as: `Commits without task reference: [N]`.

---

## Phase 4: Generate Internal Changelog

```markdown
# Internal Changelog: [Version]
Date: [Date]
Sprint(s): [Sprint numbers covered]
Commits: [Count] ([first-hash]..[last-hash])

## New Features
- [Feature Name] -- [Technical description, affected systems]
  - Commits: [hash1], [hash2]
  - Owner: [who implemented it]
  - Design doc: [link if applicable]

## Improvements
- [Improvement] -- [What changed technically and why]
  - Commits: [hashes]
  - Owner: [who]

## Bug Fixes
- [BUG-ID] [Description of bug and root cause]
  - Fix: [What was changed]
  - Commits: [hashes]
  - Owner: [who]

## Balance Changes
- [What was tuned] -- [Old value -> New value] -- [Design intent]
  - Owner: [who]

## Technical Debt / Refactoring
- [What was cleaned up and why]
  - Commits: [hashes]

## Miscellaneous
- [Change that didn't fit other categories, or vague commit message]
  - Commits: [hashes]

## Known Issues
- [Issue description] -- [Severity] -- [ETA for fix if known]

## Metrics
- Total commits: [N]
- Files changed: [N]
- Lines added: [N]
- Lines removed: [N]
- Commits without task reference: [N]
```

---

## Phase 5: Generate Player-Facing Changelog

```markdown
# What is New in [Version]

## New Features
- **[Feature Name]**: [Player-friendly description of what they can now do
  and why it is exciting. Focus on the experience, not the implementation.]

## Improvements
- **[What improved]**: [How this makes the game better for the player.
  Be specific but avoid jargon.]

## Bug Fixes
- Fixed an issue where [describe what the player experienced, not what was
  wrong in the code]
- Fixed [player-visible symptom]

## Balance Changes
- [What changed in player-understandable terms and the design intent.
  Example: "Healing potions now restore 50 HP (up from 30) -- we felt
  players needed more recovery options in late-game encounters."]

## Known Issues
- We are aware of [issue description in player terms] and are working on a
  fix. [Workaround if one exists.]

---
Thank you for playing! Your feedback helps us make the game better.
Report issues at [link].
```

---

## Phase 6: Output

Output both changelogs to the user. The internal changelog is the primary working document. The player-facing changelog is ready for community posting after review.

---

## Phase 7: Offer File Write

After presenting the changelogs, ask the user:

> "May I write this changelog to `docs/CHANGELOG.md`?
> [A] Yes, append this entry (recommended if the file already exists)
> [B] Yes, overwrite the file entirely
> [C] No — I'll copy it manually"

- Check whether `docs/CHANGELOG.md` exists before asking. If it does, default the
  recommendation to **[A] append**.
- If the user selects [A]: append the new internal changelog entry to the top of
  the existing file (newest entries first).
- If the user selects [B]: overwrite the file with the new changelog.
- If the user selects [C]: stop here without writing.

After a successful write: Verdict: **CHANGELOG WRITTEN** — changelog saved to `docs/CHANGELOG.md`.
If the user declines: Verdict: **COMPLETE** — changelog generated.

---

## Phase 7: Next Steps

- Use `/patch-notes [version]` to generate a styled, saved version for public release.
- Use `/release-checklist` before publishing the changelog externally.

### Guidelines

- Never expose internal code references, file paths, or developer names in the player-facing changelog
- Group related changes together rather than listing individual commits
- If a commit message is unclear, check the associated files and sprint data for context
- Balance changes should always include the design reasoning, not just the numbers
- Known issues should be honest — players appreciate transparency
- If the git history is messy (merge commits, reverts, fixup commits), clean up the narrative rather than listing every commit literally

## Dónde encaja

- Categoría: [Herramientas para desarrolladores](https://skillsagentes.com/categorias/herramientas-desarrollo.md) — Skills que cambian cómo tu agente escribe, revisa y despliega código.
- Creador: [Donchitos](https://skillsagentes.com/creators/donchitos.md) — 73 skills en el directorio
- [Todas las skills](https://skillsagentes.com/skills.md)
- [Ranking de instalaciones](https://skillsagentes.com/ranking.md)

## Otras skills del mismo repositorio

- [Team Qa](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-qa.md): Orquesta al equipo de QA (qa-lead y qa-tester) para producir un paquete completo de QA: plan de pruebas, smoke check, casos de prueba, ejecución manual y reporte de sign-off.
- [Consistency Check](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/consistency-check.md): Compara todos los GDDs contra el registro de entidades para detectar inconsistencias entre documentos: mismo stat, ítem o fórmula con valores distintos, usando un enfoque grep-first.
- [Create Architecture](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-architecture.md): Redacción guiada, sección por sección, del documento de arquitectura maestro del juego, consciente de la versión del motor y de sus posibles brechas de conocimiento.
- [Day One Patch](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/day-one-patch.md): Prepara un patch day-one para el lanzamiento de un juego: define alcance, prioriza, implementa y valida con un QA gate ligero, como un mini-sprint con plan de rollback.
- [Hotfix](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/hotfix.md): Flujo de arreglo urgente que se salta el proceso normal de sprint pero deja rastro de auditoría completo: crea rama hotfix, registra aprobaciones y asegura el backport correcto.

---

Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)