Manages the full release process including versioning, CHANGELOG, git tags, and publishing. Use when preparing a release or version bump.
Activar cuando el usuario diga: "prepara release", "versiona", "crea release", "bump version", "publica versión"
Este skill sigue Semantic Versioning y Conventional Commits
Analizar los commits desde el último tag para determinar el bump:
PATCH (0.0.X) → Solo commits tipo fix, chore, docs
MINOR (0.X.0) → Al menos un commit tipo feat
MAJOR (X.0.0) → Hay commits con BREAKING CHANGE o feat! / fix!
Ejecutar: git log [LAST_TAG]..HEAD --oneline para ver los commits.
Clasificar commits en secciones y agregar a CHANGELOG.md:
## [X.Y.Z] — YYYY-MM-DD
### Added
- feat(scope): descripción
### Fixed
- fix(scope): descripción
### Changed
- refactor(scope): descripción
### Breaking Changes ⚠️
- feat!(scope): descripción — **BREAKING:** detalle del breaking change
Dependiendo del ecosistema del proyecto, actualizar:
| Ecosistema | Archivo | Campo |
|---|---|---|
| Node.js | package.json | "version" |
| Python | pyproject.toml | version = |
| Rust | Cargo.toml | version = |
| Java/Maven | pom.xml | <version> |
| Go | go.mod + tag | (via tag) |
git add CHANGELOG.md [archivos de versión]
git commit -m "chore(release): v[X.Y.Z]"
git tag -a v[X.Y.Z] -m "Release v[X.Y.Z]"
⚠️ NO hacer
git pushautomáticamente. El usuario debe confirmarlo.
.env.example## Release Candidate: v[X.Y.Z]
**Tipo de bump:** MAJOR | MINOR | PATCH
**Razón:** [commits que determinaron el tipo]
### Cambios incluidos ([N] commits)
[lista del changelog generado]
### Checklist
- [x] CHANGELOG.md actualizado
- [x] Versión bumpeada en [archivos]
- [ ] Tests verificados (pendiente)
### Próximos pasos
1. Revisar y confirmar el changelog
2. Ejecutar suite de tests completa
3. Hacer push: `git push origin main --tags`