Lar

Skill

Documentação

release-notes

phuryn/pm-skills

Transforme tickets técnicos, PRDs ou registros de alterações em notas de lançamento bem elaboradas e voltadas para o usuário, organizadas por categoria.

...Expandir tudo

Tempo atualizado 29 de Setembro de 2026

# markdown # changelog # linear # jira # release notes # product documentation

Gerador de Notas de Lançamento

Transforme tickets técnicos, PRDs ou registros de alterações internos em notas de lançamento bem elaboradas e voltadas para o usuário.

Contexto

Você está escrevendo notas de lançamento para $ARGUMENTS.

Se o usuário fornecer arquivos (exportações do JIRA, tickets do Linear, PRDs, logs do Git ou registros de alterações internos), leia-os primeiro. Se eles mencionarem uma URL do produto, use uma pesquisa na web para entender o produto e o público-alvo.

Instruções

Reúna o material bruto: leia todos os tickets, registros de alterações ou descrições fornecidos. Extraia:
- O que mudou (recurso, melhoria ou correção)
- Quem é afetado (qual segmento de usuários)
- Por que isso é importante (o benefício para o usuário)
Categorize as alterações:
- Novos recursos: Funcionalidades totalmente novas
- Melhorias: aprimoramentos em recursos existentes
- Correções de bugs: Problemas resolvidos
- Alterações significativas: tudo o que exija ação do usuário (migrações, alterações na API)
- Descontinuações: Recursos que serão descontinuados
Escreva cada entrada seguindo estes princípios:
- Comece destacando o benefício para o usuário, não a alteração técnica
- Use linguagem simples — evite jargões, codinomes internos ou números de tickets
- Mantenha cada entrada entre 1 e 3 frases
- Inclua imagens ou capturas de tela, caso o usuário as forneça
Exemplos de transformações:
- Técnica: “Implementada camada de cache Redis para endpoints da API do painel”
- Para o usuário: “Os painéis agora carregam até três vezes mais rápido, então você gasta menos tempo esperando e mais tempo analisando.”
- Técnico: “Corrigida a condição de corrida no fluxo de checkout simultâneo”
- Para o usuário: “Corrigimos um problema em que alguns pedidos podiam falhar durante períodos de alto tráfego.”

Estruture as notas de lançamento:

# [Nome do produto] — [Versão / Data]

## Novos recursos
- **[Nome do recurso]**: [Descrição de 1 a 2 frases sobre o que ele faz e por que é importante]

## Melhorias
- **[Área]**: [O que melhorou e como isso ajuda]

## Correções de bugs
- Corrigido [descrição do problema em termos de usuário]

## Mudanças significativas (se houver)
- **Ação necessária**: [O que os usuários precisam fazer]

Adapte o tom para corresponder à voz do produto — profissional para B2B, amigável para o consumidor, voltado para desenvolvedores no caso de APIs.

Salve como um documento Markdown. Se o usuário quiser HTML ou outro formato, converta conforme necessário.

Ver no GitHub

---
name: release-notes
description: Transform technical tickets, PRDs, or changelogs into polished, user-facing release notes organized by category.
---

## Release Notes Generator

Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.

### Context

You are writing release notes for **$ARGUMENTS**.

If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.

### Instructions

1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract:
   - What changed (feature, improvement, or fix)
   - Who it affects (which user segment)
   - Why it matters (the user benefit)

2. **Categorize changes**:
   - **New Features**: Entirely new capabilities
   - **Improvements**: Enhancements to existing features
   - **Bug Fixes**: Issues resolved
   - **Breaking Changes**: Anything that requires user action (migrations, API changes)
   - **Deprecations**: Features being sunset

3. **Write each entry** following these principles:
   - Lead with the user benefit, not the technical change
   - Use plain language — avoid jargon, internal codenames, or ticket numbers
   - Keep each entry to 1-3 sentences
   - Include visuals or screenshots if the user provides them

   **Example transformations**:
   - Technical: "Implemented Redis caching layer for dashboard API endpoints"
   - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."

   - Technical: "Fixed race condition in concurrent checkout flow"
   - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."

4. **Structure the release notes**:

   ```
   # [Product Name] — [Version / Date]

   ## New Features
   - **[Feature name]**: [1-2 sentence description of what it does and why it matters]

   ## Improvements
   - **[Area]**: [What got better and how it helps]

   ## Bug Fixes
   - Fixed [issue description in user terms]

   ## Breaking Changes (if any)
   - **Action required**: [What users need to do]
   ```

5. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.

Save as a markdown document. If the user wants HTML or another format, convert accordingly.