Gerador de Notas de Release
Transforme um sprint de tickets fechados em notas de release polidas para o usuário — automaticamente.
Escrever notas de release a partir de tickets brutos é tedioso: filtrar trabalho interno, traduzir jargão de engenharia para linguagem de usuário, formatar de forma consistente. Este skill faz tudo isso.
Template de Prompt
/schedule
### Passo 1 — Reúna tickets concluídos
Verifique {{TICKET_SOURCES}} por itens marcados como concluídos, enviados, mesclados ou fechados nos últimos {{TIME_WINDOW}}.
Pule: em andamento, internos apenas, correções de bugs sem mudança visual no UX, tarefas, refatorações,
qualquer coisa marcada como "internal", "infra" ou "ops".
### Passo 2 — Agrupe por área de produto
Use labels de ticket ou nomes de projeto. Mescle áreas com menos de 2 itens no grupo mais próximo.
### Passo 3 — Escreva as notas de release
Para cada área:
**[Área]**
**[Título]** — 2–5 palavras, tempo presente, nome da funcionalidade não uma mensagem de commit.
Bom: "Resultados de busca mais rápidos", "Novo dashboard de faturamento". Nunca: "adicionado", "corrigido", "enviado".
[Descrição] — 1–3 frases para o usuário. Comece com o que mudou e por que é importante.
Use a estrutura "você agora pode…". Sem marcadores. Sem IDs de ticket, nomes de sprint ou nomes de engenheiros.
### Passo 4 — Salve
Data no topo: Mês DD, AAAA. Entradas agrupadas por área.
Salve como ReleaseNotes_AAAA-MM-DD.docx em {{OUTPUT_FOLDER}}.
Não publique — salve apenas para revisão. Se nenhum ticket for encontrado, diga quais fontes você verificou.
Configuração
| Campo | Valor |
|---|---|
| MCPs necessários | Linear / Jira / GitHub Issues, Google Drive |
| Saída | ReleaseNotes_AAAA-MM-DD.docx → /Product/ReleaseNotes |
| Agendador | Manual antes de cada release, ou semanalmente |
Espaços reservados para preencher
{{TICKET_SOURCES}}— ex.:Linear,JiraouGitHub Issues{{TIME_WINDOW}}— ex.:nos últimos 7 dias,nas últimas 2 semanasouneste sprint{{OUTPUT_FOLDER}}— ex.:/Product/ReleaseNotes
Dicas
- Boa higiene de tickets = melhores notas de release. Descrições que dizem "os usuários agora podem…" produzem os melhores resultados.
- Combine com
update-knowledge-basepara marcar quais artigos de ajuda precisam de atualização após cada release. - Para mudanças de API/webhook, mantenha esses tickets em uma label separada — o skill dá a eles uma voz técnica distinta.