release

Habilidad de Lanzamiento

Un asistente de lanzamiento ligero y consciente del repositorio. En la primera ejecución, inspecciona el proyecto y el CI para derivar reglas de lanzamiento, las almacena en .omc/RELEASE_RULE.md para uso futuro, y luego te guía a través de un lanzamiento usando esas reglas.

Uso

/oh-my-claudecode:release [versión]

• versión es opcional. Si se omite, la habilidad preguntará. Acepta patch, minor, major o un semver explícito como 2.4.0.
• Agrega --refresh para forzar un nuevo análisis del repositorio incluso si ya existe un archivo de reglas en caché.

Flujo de Ejecución

Paso 0 — Cargar o Construir Reglas de Lanzamiento

Verifica si existe .omc/RELEASE_RULE.md.

Si NO existe (o se pasó --refresh): Ejecuta el análisis completo del repositorio a continuación y escribe el archivo.

Si EXISTE: Lee el archivo. Luego realiza una comprobación delta rápida: escanea .github/workflows/ (o directorios CI equivalentes: .circleci/, .travis.yml, Jenkinsfile, bitbucket-pipelines.yml, gitlab-ci.yml) en busca de modificaciones más recientes que la marca de tiempo last-analyzed en el archivo de reglas. Si los archivos de workflow relevantes cambiaron, vuelve a ejecutar el análisis para esas secciones y actualiza el archivo. Informa qué cambió.

---

Paso 1 — Análisis del Repositorio (primera ejecución o --refresh)

Inspecciona el repositorio y responde lo siguiente. Escribe las respuestas en .omc/RELEASE_RULE.md.

1a. Fuentes de Versión

• Localiza todos los archivos que contienen una cadena de versión que coincida con la versión actual en package.json / pyproject.toml / Cargo.toml / build.gradle / archivo VERSION / etc.
• Lista cada archivo y el campo o patrón regex utilizado para encontrar la versión.
• Detecta si existe un script de automatización de lanzamiento (por ejemplo, scripts/release.*, objetivo Makefile release, bump2version, release-it, semantic-release, changesets, goreleaser).

1b. Registro / Distribución

• npm (package.json con publishConfig o npm publish en CI), PyPI (pyproject.toml + twine/flit), Cargo (Cargo.toml), Docker (Dockerfile + paso de push), GitHub Packages, otros.
• ¿Hay un paso de CI que publique automáticamente al hacer push de una etiqueta? ¿Qué archivo de workflow y trabajo?

1c. Activador de Lanzamiento

• Identifica qué inicia el lanzamiento: push de etiqueta (v*), despacho manual (workflow_dispatch), fusión a main/master, fusión de una rama de lanzamiento, un patrón de mensaje de commit.

1d. Puerta de Pruebas

• Identifica el comando de prueba y dónde se ejecuta en CI.
• ¿Se requieren pruebas aprobadas antes de publicar? Anota cualquier bandera de omisión.

1e. Notas de Lanzamiento / Changelog

• ¿Existe un CHANGELOG.md o CHANGELOG.rst?
• ¿Qué convención se utiliza: Keep a Changelog, Conventional Commits, auto-generado por GitHub, ninguna?
• ¿Hay un archivo de cuerpo de lanzamiento (por ejemplo, .github/release-body.md) comprometido antes de la etiqueta?

1f. Verificación de Usuario Primerizo

• ¿Existe un workflow de lanzamiento en .github/workflows/ (o equivalente)? Si no, márcalo y ofrece crear uno.
• ¿Hay una entrada en .gitignore que evite que los artefactos de compilación se comprometan? Si no, márcalo.
• ¿Se están utilizando etiquetas git? Ejecuta git tag --list para verificar. Si no existen etiquetas, márcalo y explica la mejor práctica.

---

Paso 2 — Escribir .omc/RELEASE_RULE.md

Crea o sobrescribe el archivo con esta estructura:

# Reglas de Lanzamiento
<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->

## Fuentes de Versión
<!-- lista de archivos + patrones -->

## Activador de Lanzamiento
<!-- qué inicia el lanzamiento -->

## Puerta de Pruebas
<!-- comando + nombre del trabajo de CI -->

## Registro / Distribución
<!-- npm, PyPI, Docker, etc. + trabajo de CI que publica -->

## Estrategia de Notas de Lanzamiento
<!-- convención + archivos -->

## Archivos de Workflow de CI
<!-- rutas a archivos de workflow relevantes -->

## Brechas de Configuración Inicial
<!-- cualquier elemento faltante encontrado durante el análisis, o "ninguno" -->

---

Paso 3 — Determinar Versión

Si el usuario proporcionó un argumento de versión, úsalo. De lo contrario:

1. Muestra la versión actual (del archivo de versión principal).
2. Muestra qué producirían patch, minor y major.
3. Pregunta al usuario cuál usar.

Valida que la versión elegida sea una cadena semver válida.

---

Paso 4 — Lista de Verificación Previa al Lanzamiento

Presenta una lista de verificación derivada de las reglas de lanzamiento. Como mínimo:

• Todos los cambios destinados a este lanzamiento están comprometidos y enviados
• CI está verde en la rama de destino
• Las pruebas pasan localmente (ejecuta el comando de la puerta de pruebas)
• El aumento de versión se aplicó a todos los archivos fuente de versión
• Notas de lanzamiento / changelog preparados (ver Paso 5)

Pregunta al usuario que confirme antes de continuar, o ejecuta cada paso si dicen "adelante".

---

Paso 5 — Guía de Notas de Lanzamiento

Ayuda al usuario a escribir buenas notas de lanzamiento. Aplica la convención que use el repositorio. Guía predeterminada cuando no se detecta ninguna convención:

Qué hace una buena nota de lanzamiento:

• Comienza con lo que cambió para los usuarios, no detalles internos de implementación.
• Agrupa por tipo: Nuevas Funcionalidades, Correcciones de Errores, Cambios Rupturistas, Deprecaciones, Interno / Tareas.
• Para cada elemento: una oración, enlace al PR o issue, crédito al autor si es externo.
• Los cambios rupturistas van primero y deben incluir una ruta de migración.
• Omite cambios que los usuarios nunca ven (refactorizaciones, ajustes de CI, cambios solo de prueba) a menos que afecten la reproducibilidad de la compilación.

Formato de entrada de ejemplo:

### Correcciones de Errores
- Corregir caída de sesión en caducidad de token (#123) — @contribuidor

Si el repositorio usa Conventional Commits, genera un borrador de changelog a partir de git log <etiqueta-anterior>..HEAD --no-merges --format="%s" agrupado por tipo de commit. Muéstralo al usuario y permite que lo edite.

---

Paso 6 — Ejecutar Lanzamiento

Usando las reglas descubiertas, recorre:

1. Aumentar versión — aplica a cada archivo fuente de versión.
2. Ejecutar pruebas — ejecuta el comando de la puerta de pruebas.
3. Comprometer — git add <archivos de versión> CHANGELOG.md y compromete con chore(release): aumentar versión a vX.Y.Z.
4. Etiquetar — git tag -a vX.Y.Z -m "vX.Y.Z" (las etiquetas anotadas se prefieren sobre las ligeras).
5. Enviar — git push origin <rama> && git push origin vX.Y.Z.
6. CI toma el control — si el activador de lanzamiento es un push de etiqueta, recuerda al usuario que CI manejará el resto (publicar, creación de lanzamiento de GitHub). Muestra el archivo de workflow de CI esperado.
7. Publicación manual — si no existe automatización de CI, lista el comando de publicación manual (por ejemplo, npm publish --access public, twine upload dist/*).

---

Paso 7 — Sugerencias de Configuración Inicial

Si se encontraron brechas en el Paso 1f, ofrece ayuda concreta:

Sin workflow de lanzamiento:

Tu repositorio no tiene un workflow de CI de lanzamiento. Un workflow de GitHub Actions activado por push de etiqueta v* es la mejor práctica más común. Puede:

• Ejecutar pruebas
• Publicar en npm/PyPI/etc.
• Crear un Lanzamiento de GitHub con tus notas de lanzamiento

¿Quieres que cree un .github/workflows/release.yml para tu pila tecnológica?

Sin etiquetas git:

Parece que este es el primer lanzamiento. Las etiquetas git permiten que GitHub, npm y otras herramientas entiendan tu historial de versiones. Crearemos tu primera etiqueta en el Paso 6.

Artefactos de compilación no gitignorados:

Los artefactos de compilación están presentes en el historial de git o no están gitignorados. Esto infla el tamaño del repositorio y crea conflictos de fusión. ¿Quieres que los agregue a .gitignore?

---

Paso 8 — Verificar

Después del envío:

• Verifica el estado de CI: gh run list --workflow=<workflow de lanzamiento> --limit=3 (si gh está disponible).
• Verifica el registro (npm, PyPI) para la nueva versión después de unos minutos.
• Confirma que se creó un Lanzamiento de GitHub: gh release view vX.Y.Z.

Reporta éxito o marca cualquier falla.

---

Notas

• Esta habilidad no codifica de forma fija ningún archivo de versión o comando específico del proyecto. Todo se deriva de la inspección del repositorio.
• .omc/RELEASE_RULE.md es un caché local. Compromételo en tu repositorio si deseas compartir las reglas derivadas con tu equipo, o agrégalo a .gitignore si prefieres que se mantenga local.
• Para monorepos complejos o espacios de trabajo con múltiples paquetes, la habilidad detectará patrones de espacio de trabajo (npm workspaces, pnpm workspaces, Cargo workspace) y se adaptará en consecuencia.