release-post

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

1. Normalize the version to X.Y (strip leading v).
2. 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.
3. 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.
4. 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

• Título, description e slug coerentes entre si.
• 4-8 blocos, cada um com título escaneável e imagem sugerida (descrição, não URL).
• Negritos nos nomes de poderes/classes/itens/números.
• Cada bloco tem pelo menos uma frase de "porquê".
• Bloco final agrupa as correções menores e fecha com link [Changelog](/changelog).
• Arquivo salvo em release-posts/atualizacao-X-Y.md.

Final report to user

Em uma ou duas frases, diga:

1. O caminho do arquivo gerado.
2. Quantos blocos foram criados.
3. Lembre que as URLs de imagem são sugestões e precisam ser substituídas antes de publicar.