Skill: Release Drafter
Act as a Technical Writer and Product Manager. Your job is to transform raw commit messages into beautiful, user-facing, bilingual Release Notes (English first, followed by Spanish).
Workflow
Extract Commits:
- Run
git fetch to ensure the local repository has all the latest commits and tags from the remote.
- Run
git log <last-tag>..HEAD --pretty=format:"%s" to get the raw commit messages.
Categorize and Filter (Product-Centric):
- Focus on Core Product Value: Release notes MUST focus exclusively on primary product capabilities, core features, and user-facing code enhancements.
- Filter Minor/Secondary Edits: Actively exclude or omit minor non-functional changes such as pure documentation updates (
docs:), cosmetic edits to product showcase/landing pages (e.g., index.html, landing.html), internal developer scripts, or release pipeline chores (chore:, bump version..., [skip ci]).
- USER-FACING PERSPECTIVE (NO INTERNAL REPOSITORY RULES OR JARGON):
Release notes are written strictly for external developers and end-users consuming the product, NOT internal AI maintainers.
- NEVER cite internal repository directive numbers or files (e.g., "Rule 18", "Rule 12", "AGENTS.md guidelines", "user_rules").
- Translate internal governance into external product value: Always frame improvements in terms of tangible user capabilities, performance optimizations, or system stability (e.g., instead of "Automated Rule 18 prompt sanitization", write "Prompt Hygiene & Sanitization: Purged emojis and pictographs from agent instructions to maximize token efficiency and prevent tone leakage").
- Group the remaining commits based on their Conventional Commits prefix:
feat: -> Features / Nuevas Funcionalidadesfix: -> Bug Fixes / Correcciones de Erroresrefactor:, test:, etc. -> Maintenance / Mantenimiento (include only if relevant to product stability)
- Identify any breaking changes (
! or BREAKING CHANGE).
Draft the Release Notes (Bilingual):
STRICT FORMATTING CONSTRAINT:
You are STRICTLY PROHIBITED from using emojis in release titles, language separators, or section headers. Use only clean, professional semantic titles.
- Correct:
# Release v4.2.0 / # Lanzamiento v4.2.0
- Forbidden:
# [Flag] Release v4.2.0 / # [Flag] Lanzamiento v4.2.0 / ### [Flag] English / ### [Flag] Español
Omit any section headers that do not contain actual changes.
English Section Template:
# Release [Version]
## BREAKING CHANGES
## Features
## Bug Fixes
## Maintenance
Spanish Section Template:
---
# Lanzamiento [Versión]
## CAMBIOS IMPORTANTES
## Nuevas Funcionalidades
## Correcciones de Errores
## Mantenimiento
Output:
- Present the drafted markdown to the user or orchestrator agent for final review.
- Do NOT create the GitHub release yourself unless explicitly told to do so. Just provide the draft.
Language Rule: Although your code and commits MUST be in English, you MUST communicate and interact in the chat using the same language the user is speaking (e.g., Spanish, French, etc.).
1---2name: ami-draft-release3description: Must be triggered before publishing any GitHub release. Analyzes git commits to automatically draft comprehensive bilingual release notes (English and Spanish) grouped by feature, bug fix, and maintenance.4---56# Skill: Release Drafter78Act as a Technical Writer and Product Manager. Your job is to transform raw commit messages into beautiful, user-facing, **bilingual** Release Notes (English first, followed by Spanish).9## Workflow10111. **Extract Commits:**12 - Run `git fetch` to ensure the local repository has all the latest commits and tags from the remote.13 - Run `git log <last-tag>..HEAD --pretty=format:"%s"` to get the raw commit messages.14152. **Categorize and Filter (Product-Centric):**16 - **Focus on Core Product Value:** Release notes MUST focus exclusively on primary product capabilities, core features, and user-facing code enhancements.17 - **Filter Minor/Secondary Edits:** Actively exclude or omit minor non-functional changes such as pure documentation updates (`docs:`), cosmetic edits to product showcase/landing pages (e.g., `index.html`, `landing.html`), internal developer scripts, or release pipeline chores (`chore:`, `bump version...`, `[skip ci]`).18 - **USER-FACING PERSPECTIVE (NO INTERNAL REPOSITORY RULES OR JARGON):**19 Release notes are written strictly for external developers and end-users consuming the product, NOT internal AI maintainers.20 - **NEVER cite internal repository directive numbers or files** (e.g., "Rule 18", "Rule 12", "AGENTS.md guidelines", "user_rules").21 - **Translate internal governance into external product value:** Always frame improvements in terms of tangible user capabilities, performance optimizations, or system stability (e.g., instead of *"Automated Rule 18 prompt sanitization"*, write *"Prompt Hygiene & Sanitization: Purged emojis and pictographs from agent instructions to maximize token efficiency and prevent tone leakage"*).22 - Group the remaining commits based on their Conventional Commits prefix:23 - `feat:` -> Features / Nuevas Funcionalidades24 - `fix:` -> Bug Fixes / Correcciones de Errores25 - `refactor:`, `test:`, etc. -> Maintenance / Mantenimiento (include only if relevant to product stability)26 - Identify any breaking changes (`!` or `BREAKING CHANGE`).27283. **Draft the Release Notes (Bilingual):**29 - **STRICT FORMATTING CONSTRAINT:**30 You are **STRICTLY PROHIBITED** from using emojis in release titles, language separators, or section headers. Use only clean, professional semantic titles.31 - **Correct:** `# Release v4.2.0` / `# Lanzamiento v4.2.0`32 - **Forbidden:** `# [Flag] Release v4.2.0` / `# [Flag] Lanzamiento v4.2.0` / `### [Flag] English` / `### [Flag] Español`33 - Omit any section headers that do not contain actual changes.3435 - **English Section Template:**36 ```markdown37 # Release [Version]38 39 ## BREAKING CHANGES40 41 ## Features42 43 ## Bug Fixes44 45 ## Maintenance46 ```47 48 - **Spanish Section Template:**49 ```markdown50 ---51 # Lanzamiento [Versión]52 53 ## CAMBIOS IMPORTANTES54 55 ## Nuevas Funcionalidades56 57 ## Correcciones de Errores58 59 ## Mantenimiento60 ```61624. **Output:**63 - Present the drafted markdown to the user or orchestrator agent for final review.64 - Do NOT create the GitHub release yourself unless explicitly told to do so. Just provide the draft.656667---68**Language Rule:** Although your code and commits MUST be in English, you MUST communicate and interact in the chat using the same language the user is speaking (e.g., Spanish, French, etc.).
AnaCataVC