| name | release-post |
| description | Generate a blog post markdown file for a new release of Fichas de Nimb. Reads the version's section in src/components/screens/Changelog.tsx, the related git commits, and produces release-posts/atualizacao-{version}.md following the established blog format (title, description, slug, cover image suggestion, content blocks with image suggestions). Use when the user asks for a release post, blog post for a version, or "post da v X.Y". |
release-post
Generate a publish-ready markdown draft for a new release blog post on https://fichasdenimb.com.br/blog.
Usage
/release-post <version>
<version> examples: 4.13, v4.13, 4.10. Normalize to X.Y internally.
What the skill must do
- Normalize the version to
X.Y (strip leading v).
- Locate the version's changelog entry in
src/components/screens/Changelog.tsx. It lives between <h3>X.Y</h3> and the next <h3> (or the closing tag of that accordion). Read the full block of <li> items.
- Get commit context with
git log --oneline -n 30 and pick out the commits relevant to this version (look for commits between release: vX.Y and the previous release: v... tag/commit). For commits whose meaning is non-obvious from the message, run git show --stat <hash> (and git show <hash> if needed) to understand what changed.
- Generate the markdown following the format in the next section. Write to
release-posts/atualizacao-{version-with-dash}.md (e.g. release-posts/atualizacao-4-13.md). Create the release-posts/ directory if it doesn't exist. Tell the user the file path at the end.
Do not publish, push, commit, or call the blog API. The file is a draft for the user to paste into the blog editor block-by-block.
Output file format
Use this exact template — frontmatter for post metadata, then ## Bloco N sections for each content block. Each block is what the user will paste into the editor as one block.
---
title: Atualização X.Y já disponível
description: <1-sentence summary, max ~140 chars, lists 2-3 main themes>
slug: atualizacao-X-Y-ja-disponivel
coverImage: <SUGESTÃO: arte de fantasia/RPG temática (ex.: dmdave.com, thegamerimages.com, arcaneeye.com). Substituir por URL real antes de publicar.>
---
## Bloco 1
**Título do bloco:** <Título específico, escaneável, dizendo o que mudou>
**Imagem sugerida:** <descrição do screenshot/arte que combina com o bloco — ex.: "Screenshot do drawer de equipamentos com o campo de busca em destaque, mostrando 'espada' filtrando 'Espada Longa'.">
**Legenda da imagem (opcional):** <só se for útil; muitos blocos não têm legenda>
<conteúdo do bloco em markdown — 1 a 3 parágrafos curtos, com **negrito** em termos do jogo e nomes de poderes/itens, *itálico* em ênfase ocasional. Listas com `-` quando agrupar várias features.>
---
## Bloco 2
(repete o padrão)
---
## Bloco N — Outras correções
**Título do bloco:** Outras correções
(ou "E tem mais na X.Y" quando for um misto de melhorias e correções menores)
**Imagem sugerida:** <opcional — esse bloco geralmente não tem imagem, ou usa a coverImage de novo como fechamento>
A vX.Y também fechou várias frentes que vinham incomodando:
- **<Nome curto da correção>:** <explicação em 1-2 linhas, com bold no termo de jogo afetado>.
- ...
A lista completa, como sempre, está no [Changelog](/changelog).
Style guide (non-negotiable — match the existing posts)
- Idioma: português brasileiro coloquial e direto. Soa como dev contando o que mudou pra um jogador, não release notes corporativos.
- Personalidade: punchy. Use construções como "Bug chato e silencioso:", "Mudança pequena, ganho diário grande.", "O maior inimigo das condições em RPG não é a regra — é esquecer que elas estão ativas." Comece blocos pelo problema/contexto quando der, não pela feature.
- Negrito: sempre em nomes de poderes, classes, itens, condições, valores numéricos importantes (ex.: +2, 1d10), nomes de telas/ações (ex.: Mochila de Aventureiro, Mesa Virtual).
- Itálico: ênfase ocasional, nomes de condições no meio do texto (ex.: paralisado), e em frases-fechamento informais (ex.: Bons jogos e que suas condições durem só uma rodada.).
- Explica o porquê: todo bloco precisa de pelo menos uma frase do porquê da mudança ou qual problema resolvia. Não basta listar a feature.
- Especificidade: prefira nomes reais (poder, classe, número) a abstrações ("um poder de uma classe"). Se o changelog cita "Casca Grossa (Lutador / Atleta)", use isso.
- Tamanho dos blocos: 1-3 parágrafos, raramente 4. Listas com
- quando há 3+ itens correlatos.
- Quantidade de blocos: 4 a 8. Combine itens correlatos do changelog num bloco só quando fizer sentido (ex.: 4 poderes de combate viraram um bloco em 4.12). Não faça 1 bloco por linha do changelog.
- Bloco final: sempre "Outras correções" ou "E tem mais na X.Y" agrupando os fixes/melhorias menores em bullets, terminando com link para
[Changelog](/changelog).
Sugestão de imagem — como pensar
Para cada bloco com mudança visual, sugira o que screenshotar, não uma URL. Padrões observados:
- Feature de UI nova → screenshot da própria UI mostrando a feature em ação.
- Mudança de regra/cálculo → screenshot da ficha mostrando o número correto, ou um print da tela onde o usuário escolhe.
- Bloco de correções → geralmente sem imagem própria.
- Bloco de fechamento informal → reusa a coverImage.
Para a coverImage, sugira o tema que combina com a feature de destaque (ex.: feature de combate → arte de luta; feature de magia → arte de mago; release misto → arte genérica de aventura). Os posts atuais usam imagens de dmdave.com, static0.thegamerimages.com, arcaneeye.com — não invente URLs, deixe a sugestão e marque como <SUGESTÃO: ...>.
Quick format reference (from real posts)
- Title: "Atualização X.Y já disponível" (default) ou "Atualização X.Y - " quando há um tema dominante (ex.: "Atualização 4.10 - Condições automáticas na atualização 2026.2").
- Description: lista 2-3 temas principais, separados por vírgula, terminando com "e mais correções." quando aplicável. Ex.: "Pesquisa nos equipamentos, mais poderes com bônus automáticos e mais correções."
- Slug:
atualizacao-X-Y-ja-disponivel (default) ou atualizacao-X-Y-<tema-em-kebab-case> quando o título tem tema.
Checklist antes de salvar
Final report to user
Em uma ou duas frases, diga:
- O caminho do arquivo gerado.
- Quantos blocos foram criados.
- Lembre que as URLs de imagem são sugestões e precisam ser substituídas antes de publicar.
