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.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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.ymldetecta 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.Zcon fecha y elegir la versión SemVer); el tag/release manual solo hace falta si el workflow no está activo.
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.## [Unreleased] de
CHANGELOG.md. Si está vacía, no hay nada que publicar: dilo y detente.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.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.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.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.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.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>".mainEl 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.
main)Un hotfix/* no pasa por develop, pero también publica versión (siempre un
patch). El orden es:
hotfix/* (nacida de main): el fix, su entrada en ## [Unreleased] y
el corte con esta skill — pasos 3 a 6, con el bump patch.hotfix/* → main. El job release lo valida y, al fusionar, release.yml
publica el tag y el release.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.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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").
日本語の概要は準備中です。原文の説明を表示しています。
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").
日本語の概要は準備中です。原文の説明を表示しています。
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").
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。
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").
日本語の概要は準備中です。原文の説明を表示しています。
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").
日本語の概要は準備中です。原文の説明を表示しています。