Release de Easymailing Skills

Analiza los cambios pendientes, determina la versión semver, actualiza el CHANGELOG, hace commit, push y crea un release en GitHub.

Flujo principal

FASE 1: Análisis de cambios
   ↓
FASE 2: Determinar versión
   ↓
FASE 3: Actualizar CHANGELOG
   ↓
FASE 4: Commit y push
   ↓
FASE 5: Crear release en GitHub

Fase 1: Análisis de cambios

Paso 1.1: Ver estado del repositorio

Ejecuta estos comandos para entender qué ha cambiado:

# Estado actual
git status

# Cambios en archivos
git diff

# Último tag/release
git describe --tags --abbrev=0 2>/dev/null || echo "No hay tags previos"

# Commits desde el último tag (si existe)
git log $(git describe --tags --abbrev=0 2>/dev/null)..HEAD --oneline 2>/dev/null || git log --oneline -10

Paso 1.2: Resumir cambios

Presenta al usuario un resumen de los cambios detectados:

## Cambios detectados

### Archivos modificados:
- kb-article/kb-article.md
- kb-article/scripts/zendesk.ts

### Resumen de cambios:
- [descripción breve de cada cambio significativo]

Fase 2: Determinar versión

Reglas de versionado semver

Analiza los cambios y determina el tipo de incremento:

MAJOR (x.0.0) - Cambios breaking:

• •Eliminar o renombrar una skill
• •Cambiar estructura de archivos de forma incompatible
• •Cambiar flujo de skill de forma que rompa uso existente

MINOR (0.x.0) - Nueva funcionalidad:

• •Añadir nueva skill
• •Añadir nuevo comando o fase a una skill existente
• •Añadir nueva integración (API, herramienta)

PATCH (0.0.x) - Correcciones y mejoras menores:

• •Corregir bugs
• •Mejorar documentación
• •Ajustar textos o formatos
• •Refactorizar sin cambiar funcionalidad

Paso 2.1: Proponer versión

Obtén la versión actual:

git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0"

Propón la nueva versión y explica por qué:

## Versión propuesta: v1.2.0

**Razón:** Se añadió nueva funcionalidad (comando `update` en zendesk.ts)

¿Te parece bien esta versión o prefieres otra?

Espera confirmación del usuario antes de continuar.

Fase 3: Actualizar CHANGELOG

Paso 3.1: Leer CHANGELOG actual

cat CHANGELOG.md

Paso 3.2: Preparar entrada del changelog

Genera la entrada para el CHANGELOG siguiendo el formato existente:

## [X.Y.Z] - YYYY-MM-DD

### Added
- Descripción de funcionalidades nuevas

### Changed
- Descripción de cambios en funcionalidades existentes

### Fixed
- Descripción de correcciones

Solo incluye las secciones que apliquen (Added, Changed, Fixed, Removed, etc.)

Paso 3.3: Actualizar CHANGELOG.md

Mueve el contenido de [Unreleased] a la nueva versión y deja [Unreleased] vacío:

## [Unreleased]

## [X.Y.Z] - YYYY-MM-DD
[contenido movido de Unreleased + cambios actuales]

Fase 4: Commit y push

Paso 4.1: Añadir archivos

git add -A

Paso 4.2: Crear commit

Usa un mensaje descriptivo que resuma los cambios:

git commit -m "feat: descripción breve de los cambios principales

- Detalle 1
- Detalle 2
- Detalle 3"

Convenciones de prefijos:

• •feat: nueva funcionalidad
• •fix: corrección de bugs
• •docs: documentación
• •refactor: refactorización

Paso 4.3: Push

git push origin main

Fase 5: Crear release en GitHub

Paso 5.1: Preparar notas del release

Las notas deben incluir:

• •Resumen de los cambios principales
• •Lista de cambios (copiada del CHANGELOG)
• •Créditos si aplica

Paso 5.2: Crear release

gh release create vX.Y.Z --title "vX.Y.Z - Título descriptivo" --notes "$(cat <<'EOF'
## Cambios en esta versión

### Added
- ...

### Changed
- ...

### Fixed
- ...
EOF
)"

Paso 5.3: Confirmar al usuario

✅ Release creado exitosamente

- **Versión:** vX.Y.Z
- **URL:** https://github.com/usuario/repo/releases/tag/vX.Y.Z
- **Commit:** [hash]

El CHANGELOG.md ha sido actualizado y los cambios están publicados.

Invocación

/release

O cuando el usuario diga:

• •"haz release"
• •"publica los cambios"
• •"sube a git"
• •"crear release"
• •"nueva versión"