跳到正文
cccskills
免费在 GitHub 公开

release

Corta una nueva versión — mueve la sección Unreleased del CHANGELOG a una versión SemVer con fecha, crea el commit y el tag, y opcionalmente el release de GitHub. Úsalo cuando la persona pida publicar/cortar una versión o preparar un release (p. ej. "corta la versión 1.2.0", "prepara el release", "publica una nueva versión"). No hace push sin confirmación.

中文简介正在准备中。当前显示原文说明。

集成工具GitHub
查看安装方法

包含的文件(1)

  • SKILL.md5.1 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Corta una versión siguiendo Keep a Changelog y Semantic Versioning (ver CHANGELOG.md y CONTRIBUTING.md).

Automatización: al fusionar develop → main, el workflow .github/workflows/release.yml detecta la versión fechada más reciente del CHANGELOG y, si no tiene tag, publica el tag y el release de GitHub solo. Esta skill prepara el corte (mover Unreleased → X.Y.Z con fecha y elegir la versión SemVer); el tag/release manual solo hace falta si el workflow no está activo.

Pasos

  1. Precondiciones. Verifica que el árbol esté limpio (git status) y que estés en la rama correcta según CONTRIBUTING.md: con Git Flow el release sale de develop hacia main, salvo un hotfix, que se corta en la propia hotfix/* (ver abajo); sin develop, desde main. Si hay cambios sin commit, detente y avisa.
  2. Leer lo pendiente. Toma las entradas de la sección ## [Unreleased] de CHANGELOG.md. Si está vacía, no hay nada que publicar: dilo y detente.
  3. Proponer la versión. Lee la última versión publicada (tag v* o CHANGELOG) y propone el bump SemVer según el contenido: cambios incompatibles → major; solo Added/Changed → minor; solo Fixed/Security → patch. Deja que la persona confirme o corrija con AskUserQuestion.
  4. Actualizar el CHANGELOG. Mueve las entradas de Unreleased a una nueva sección ## [X.Y.Z] - YYYY-MM-DD (fecha de hoy), deja Unreleased con sus categorías vacías y actualiza los enlaces de comparación del pie del archivo.
  5. Sincronizar la versión del manifiesto. Si el stack tiene un archivo que declara versión, súbela a X.Y.Z en el mismo commit — si no, el proyecto publica v0.4.0 con el manifiesto diciendo 0.1.0. Busca el que aplique y actualiza también su lockfile si el gestor lo regenera:
    • package.json (+ package-lock.json / pnpm-lock.yaml) · *.gemspec o lib/**/version.rb · Cargo.toml (+ Cargo.lock) · pyproject.toml · composer.json · pubspec.yaml · build.gradle · VERSION.
    • Si no hay ninguno (proyecto sin manifiesto versionado), dilo y sigue: el CHANGELOG es la única fuente de la versión.
  6. Commit, sin tag. Crea el commit chore(release): vX.Y.Z (con la coautoría de IA de docs/conventions/ai-agents.md) en una rama chore/corte-vX.Y.Z — recuerda que git-guardrails.sh no deja commitear directo en develop. NO crees ni publiques el tag aquí. release.yml solo publica si la versión no tiene tag: si lo creas tú, el workflow la da por publicada, no crea el release de GitHub, y encima el tag apunta al commit de la rama en vez de al merge en main.
  7. Llevarlo a producción. PR de la rama de corte → develop, y después PR develop → main. Al fusionar en main, release.yml crea el tag vX.Y.Z sobre el merge y publica el release con las notas de esa sección del CHANGELOG.
  8. Solo si el workflow no está activo (proyecto sin Actions, o release.yml borrado): entonces sí, tag anotado a mano y gh release create vX.Y.Z --title "vX.Y.Z" --notes "<sección del CHANGELOG>".

El corte es lo último antes de fusionar a main

El job release de quality.yml (.github/scripts/check-release.sh) bloquea los PRs hacia main si la versión de arriba del CHANGELOG ya está publicada, si quedaron entradas sueltas en ## [Unreleased], o si esa versión es heredada de la plantilla (un CHANGELOG sin resetear deja arriba la última versión del repositorio origen). Es la misma regla dicha al revés: nada llega a producción sin versión. Si el PR a main falla por eso, no lo esquives — corta la versión.

Hotfix (release desde main)

Un hotfix/* no pasa por develop, pero también publica versión (siempre un patch). El orden es:

  1. En la rama hotfix/* (nacida de main): el fix, su entrada en ## [Unreleased] y el corte con esta skill — pasos 3 a 6, con el bump patch.
  2. PR hotfix/* → main. El job release lo valida y, al fusionar, release.yml publica el tag y el release.
  3. Sincroniza a develop con un PR main → develop (lo exige CONTRIBUTING.md): si te lo saltas, develop no tiene ni el fix ni la sección de versión del CHANGELOG, y el próximo corte la pisa.

Ejemplo: "corta la versión" → propone v1.3.0 → CHANGELOG actualizado + commit en chore/corte-v1.3.0; el tag y el release los pone release.yml al llegar a main.

NO crees el tag a mano cuando release.yml esté activo (le robas el release), NO hagas push ni publiques sin confirmación explícita, NO inventes entradas de changelog que no estén en Unreleased, y NO saltes una versión SemVer.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Revisa los cambios de UI en cuanto a accesibilidad — contraste de color, navegación por teclado, gestión del foco, uso de ARIA y texto alternativo. Úsalo cuando la persona pida una revisión de a11y/accesibilidad, verificar el cumplimiento de WCAG, el soporte de teclado, la compatibilidad con lectores de pantalla o el manejo del foco (p. ej. "¿es accesible este modal?", "audita la a11y del formulario").

中文简介正在准备中。当前显示原文说明。

brayandiazc/project-starter-template-es-ai152026年9月23日 更新

Trae a este proyecto las mejoras que la plantilla de origen recibió después de la instanciación — lee .template-origin, calcula el diff del tooling (skills, hooks, scripts, workflows) contra la plantilla actual y propone aplicarlo. Úsalo cuando la persona quiera actualizar/sincronizar el proyecto con la plantilla (p. ej. "actualiza la plantilla", "trae las mejoras nuevas del template").

中文简介正在准备中。当前显示原文说明。

brayandiazc/project-starter-template-es-ai152026年9月23日 更新

changelog

免费

Actualiza CHANGELOG.md en el formato Keep a Changelog, añadiendo los cambios actuales bajo la sección Unreleased. Úsalo cuando la persona pida actualizar el changelog, añadir una entrada al changelog o registrar lo que cambió para las notas de la versión (p. ej. "añade esto al changelog", "actualiza el CHANGELOG con estos commits").

中文简介正在准备中。当前显示原文说明。

brayandiazc/project-starter-template-es-ai152026年9月23日 更新

commit

免费

Escribe un mensaje de Conventional Commits para los cambios en stage y crea el commit, incluyendo la línea de coautoría de atribución de IA. Úsalo cuando la persona pida hacer commit, escribir un mensaje de commit o guardar cambios (p. ej. "haz commit de esto", "escribe un mensaje de commit para estos cambios"). No hace push.

中文简介正在准备中。当前显示原文说明。

brayandiazc/project-starter-template-es-ai152026年9月23日 更新

Configura el repositorio de GitHub de punta a punta con gh — descripción, topics, labels, rama develop, protección de ramas, merge settings y metadatos — a partir de la definición del producto. Úsalo al crear el repo de un proyecto nuevo o cuando haya que poner en orden uno existente (p. ej. "configura el repo", "prepara el repositorio en GitHub", "pon los labels y la protección de ramas").

中文简介正在准备中。当前显示原文说明。

brayandiazc/project-starter-template-es-ai152026年9月23日 更新

Revisa o produce textos visibles para la persona usuaria (texto de UI, encabezados, botones, mensajes de error, marketing) con la voz y el tono del proyecto. Úsalo cuando la persona pida escribir/mejorar textos, corregir la redacción, revisar el tono o redactar microcopy (p. ej. "escribe el texto del estado vacío", "haz este mensaje de error más amable", "revisa el titular de la landing").

中文简介正在准备中。当前显示原文说明。

brayandiazc/project-starter-template-es-ai152026年9月23日 更新

查看 brayandiazc 的全部技能

报告此技能的问题