Escritor de Posts de Blog

O que Escritor de Posts de Blog faz?

Escreva posts de blog de alta qualidade a partir de mudanças de código, briefings de marketing ou descrições de funcionalidades. Cuida de SEO, estrutura, correspondência de tom e conteúdo visual.

Regra de escrita (innegociável): nunca use travessões (— ou –). Use um hífen - no lugar. Aplica-se a cada linha de texto gerado.

Resolução de Entrada

Resolva o argumento (se fornecido) nesta ordem:

1. Caminho para um arquivo de briefing de marketing existente (.md contendo "Executive Summary" ou "Key Messages") → briefing de marketing
2. Corresponde a URL do GitHub ou padrão #\d+ → PR
3. Contém ... ou .. → intervalo de refs git
4. Resolve para arquivo/diretório existente → funcionalidade do código
5. Caso contrário → texto livre

Se nenhum argumento for fornecido, pergunte: "Sobre o que devo escrever? Você pode fornecer um caminho de briefing de marketing, URL/número de PR, intervalo de refs git (ex.: v1.0...v2.0), caminho de arquivo/diretório ou apenas descrever o tópico."

Se múltiplas interpretações coincidirem, confirme com o usuário.

Fluxo do Processo

digraph blog_post {
    rankdir=TB;
    "Resolver entrada" [shape=box];
    "Fase 1: Descoberta" [shape=box];
    "Fase 2: Pesquisa" [shape=box];
    "Fase 3: Configuração" [shape=box];
    "Fase 4: Esboço" [shape=box];
    "Esboço aprovado?" [shape=diamond];
    "Fase 5: Escrever" [shape=box];
    "Fase 6: Saída" [shape=box];

    "Resolver entrada" -> "Fase 1: Descoberta";
    "Fase 1: Descoberta" -> "Fase 2: Pesquisa";
    "Fase 2: Pesquisa" -> "Fase 3: Configuração";
    "Fase 3: Configuração" -> "Fase 4: Esboço";
    "Fase 4: Esboço" -> "Esboço aprovado?";
    "Esboço aprovado?" -> "Fase 4: Esboço" [label="não, revise"];
    "Esboço aprovado?" -> "Fase 5: Escrever" [label="sim"];
    "Fase 5: Escrever" -> "Fase 6: Saída";
}

NÃO pule fases. Faça perguntas em um ritmo natural. Não sobrecarregue, mas também não atrase artificialmente. Se o usuário responder várias perguntas de uma vez, aceite as respostas agrupadas e avance.

Se o usuário disser "apenas escolha os padrões", "você decide" ou similar, escolha padrões razoáveis com base no contexto, informe o que escolheu e peça uma única confirmação antes de prosseguir.

Nunca faça suposições sem confirmar.

Fase 1: Descoberta

Passo 1 - Analise a entrada

Tipo de entrada	O que ler
Briefing de marketing	Leia o briefing - extraia declaração do problema, proposta de valor, público, mensagens-chave, posicionamento competitivo. Ainda faça o Passo 2 se o briefing faltar contexto do produto, depois prossiga para o Passo 3.
PR	Diff, descrição do PR, comentários de revisão, mensagens de commit (gh pr view, gh pr diff). Para PRs grandes (20+ arquivos), foque em mudanças voltadas ao usuário.
Refs git	git diff e git log entre os refs. Para intervalos grandes, priorize mensagens de commit e mudanças voltadas ao usuário.
Funcionalidade do código	Leia os arquivos/diretórios especificados.
Texto livre	Analise a descrição do usuário. Se faltar especificidades (sem nome de funcionalidade, sem proposta de valor, sem contexto), peça ao usuário para fornecer mais detalhes ou apontar para um arquivo/PR específico. Recurso a perguntas abertas apenas se ele não puder.

Mudanças voltadas ao usuário incluem: novas funcionalidades, mudanças de UI, mudanças de API, melhorias de desempenho, correções de bugs e atualizações de documentação. Mudanças internas incluem: refatorações, adição de testes, mudanças de CI e atualizações de dependências. Quando em dúvida, liste o que encontrou e pergunte ao usuário quais são relevantes.

Tratamento de erros:

• gh não instalado/autenticado → informe o usuário, sugira gh auth login, ofereça entrada alternativa
• PR/ref inválido → informe ao usuário, peça para verificar
• Arquivo não encontrado → peça o caminho correto

Passo 2 - Leia o contexto mais amplo do produto

Leia se existirem: README, docs/, package.json (ou equivalente), referências de marketing.

Objetivo: entender o que é o produto, para quem é, o que ele faz.

Se nada for encontrado, pergunte: "Não encontrei contexto do produto no repositório. Você pode descrever brevemente o produto e para quem ele é?"

Passo 3 - Apresente o entendimento

"Aqui está o que entendi:"

• Funcionalidade A - descrição curta
• Funcionalidade B - descrição curta

"Quais dessas o post do blog deve cobrir? Algo a adicionar, remover ou corrigir?"

Faça quantas perguntas forem necessárias para entender completamente o escopo. NÃO prossiga até que o usuário confirme.

Passo 4 - Sinalize itens sensíveis

Verifique por: mudanças que quebram compatibilidade, deprecações, correções de segurança, requisitos de migração.

Se encontrado, sinalize cada um e pergunte como enquadrá-los antes de prosseguir.

Fase 2: Pesquisa de Blogs Concorrentes

Antes de configurar o post, pesquise posts de blog semelhantes no espaço:

1. Use WebSearch para encontrar 3-5 posts de blog existentes cobrindo o mesmo tópico, produtos concorrentes ou anúncios de funcionalidades similares
2. Analise o que funciona e o que não funciona nesses posts - estrutura, manchetes, ganchos, palavras-chave de SEO, profundidade
3. Identifique lacunas de conteúdo - o que os concorrentes NÃO estão cobrindo que este post poderia
4. Use essas descobertas para informar a estratégia de SEO, geração de manchetes e estrutura de conteúdo

Se WebSearch não estiver disponível, pule esta fase e confie no seu próprio conhecimento.

Apresente um breve resumo ao usuário:

"Encontrei alguns posts semelhantes no espaço. Aqui está o que notei:"

• [Descobertas principais sobre o que funciona]
• [Lacunas de conteúdo / oportunidades]
• [Oportunidades de palavras-chave de SEO]

"Vou usar esses insights para moldar o post."

Fase 3: Configuração

Faça estas perguntas:

P1 - Público: "Para quem é este post de blog?" (desenvolvedores, usuários finais, tomadores de decisão técnica, público geral, outro)

P2 - Tom: Leia posts de blog existentes, README e docs no repositório para detectar a voz do produto. Depois confirme:

"Com base no seu conteúdo existente, o tom parece [ex.: conversacional e amigável para desenvolvedores]. Devo combinar isso ou seguir uma direção diferente?"

Se não houver conteúdo existente para analisar, pergunte diretamente ao usuário qual tom ele deseja.

P3 - Tipo de post: Com base na entrada e no público, recomende um tipo de post e confirme:

• Anúncio de funcionalidade - "Lançamos X, aqui está por que importa" (~600-1000 palavras)
• Técnico aprofundado - "Como construímos X, as decisões e arquitetura" (~1500-2500 palavras)
• Narrativa problema-solução - "Você tem o problema X, aqui está como isso resolve" (~1000-2000 palavras)

"Dado [entrada/público], recomendo um post [tipo] porque [motivo]. Parece certo?"

P4 - CTA: Infira a chamada para ação mais apropriada a partir do contexto:

• Open source → estrelar o repositório, contribuir, experimentar
• SaaS → inscreva-se, inicie teste gratuito
• Atualização de funcionalidade → experimente a nova funcionalidade, leia a documentação
• Biblioteca/SDK → instale, leia o guia de migração

"Eu sugeriria que o CTA fosse: [CTA inferido]. Quer seguir com isso ou algo diferente?"

P5 - Nível de envolvimento: "Quão envolvido você quer estar no processo de escrita?"

• A) Apenas escreva - Eu cuido de tudo, escolho a melhor manchete e salvo o post final. Você pode solicitar alterações depois.
• B) Mostre-me o esboço primeiro - aprove a estrutura, depois escrevo o post completo
• C) Guie-me por ele - aprovação do esboço, depois seção por seção com confirmação

Fase 4: Esboço

Gere um esboço estruturado:

## [Título de trabalho]

1. **Gancho/Introdução** - [abordagem: pergunta/estatística/afirmação ousada/história]
   - Ponto-chave a estabelecer
   - Transição para o corpo

2. **Nome da Seção** - [propósito]
   - Pontos-chave
   - Contagem estimada de palavras

3. **Nome da Seção** - [propósito]
   - Pontos-chave
   - Contagem estimada de palavras

[...quantas seções forem necessárias]

N. **Conclusão** - [resumo + CTA]
   - Principal lição a reforçar
   - CTA: [ação específica]

Total estimado: ~X palavras

Se o nível de envolvimento for A, gere o esboço internamente sem mostrá-lo. Para B e C, apresente-o e aguarde aprovação.

Fase 5: Escrever

Processo interno de escrita (sempre executado, independentemente do nível de envolvimento)

Para cada seção:

1. Escreva a seção
2. Auto-revisão: analise se o conteúdo poderia ser estruturado de forma diferente, se está faltando contexto que o leitor precisa para entender e digerir, ou se há lacunas que confundiriam alguém não familiarizado com o tópico
3. Preenchimento: se peças faltantes forem encontradas, adicione parágrafos de ligação, contexto ou reestruture antes de prosseguir

Se o nível de envolvimento for C, apresente cada seção após a auto-revisão e obtenha confirmação antes de prosseguir. Para A e B, execute este processo silenciosamente.

Manchetes

Após o corpo estar completo, gere 3-5 opções de manchete usando fórmulas diferentes:

• Como fazer ("Como [Produto] resolve [problema]")
• Número/lista ("3 razões pelas quais [funcionalidade] muda [fluxo de trabalho]")
• Pergunta ("Cansado de [ponto de dor]?")
• Afirmação ousada ("[Funcionalidade] é a maneira mais rápida de [resultado]")
• Antes/depois ("[Dor] → [Resultado]: Como [funcionalidade] torna isso possível")

Recomende uma e explique por que funciona melhor para o público, SEO e contexto deste post. Explique também os trade-offs das outras.

Para níveis de envolvimento B e C, apresente as opções e obtenha a seleção do usuário antes de prosseguir. Para o nível A, use sua recomendação.

Priorize a legibilidade sobre restrições de SEO. Escreva a melhor manchete primeiro. Se ela não se encaixar no limite de 50-60 caracteres de título de SEO, crie uma tag de título separada e mais curta para o frontmatter.

Frontmatter de SEO

Gere como frontmatter YAML no topo do post:

---
title: "[Manchete selecionada]"
meta_description: "[140-160 caracteres, inclui palavra-chave principal, proposta de valor convincente]"
primary_keyword: "[palavra-chave alvo principal]"
secondary_keywords: ["keyword1", "keyword2", "keyword3"]
long_tail_keywords: ["frase longa 1", "frase longa 2"]
slug: "[slug-amigável-para-url]"
---

Regras:

• Tag de título: 50-60 caracteres, palavra-chave principal no início
• Meta descrição: 140-160 caracteres, escrita para humanos, inclui proposta de valor única
• Palavras-chave informadas pela pesquisa competitiva da Fase 2
• Sem excesso de palavras-chave - linguagem natural apenas

Regras de formatação de conteúdo

• Parágrafos curtos: máximo de 2-4 frases
• Subtítulos: use H2 para seções principais, H3 para subseções. Subtítulos devem funcionar como um esboço escaneável por conta própria.
• Negrite frases-chave para apoiar a varredura em padrão F
• Pontos de bala e listas para qualquer conjunto de 3+ itens
• Uma ideia por parágrafo
• Nunca use travessões no conteúdo gerado. Sem caracteres "—". Use vírgulas, dois-pontos, pontos ou parênteses no lugar.

Gancho/Introdução

A introdução tem três componentes:

1. Gancho (primeiras 1-2 frases) - uma estatística surpreendente, afirmação ousada, ponto de dor relacionável ou pergunta provocativa. Deve criar curiosidade ou ressonância emocional em menos de 3 segundos de leitura.
2. Autoridade - estabeleça brevemente por que isso importa ou por que o leitor deve confiar nisso
3. Promessa - declare claramente o que o leitor obterá deste post

Mantenha a introdução em 3-5 parágrafos curtos. Sem blocos de texto.

Conclusão

1. Reafirme a principal lição (não introduza novas ideias)
2. CTA único e claro com verbo de ação ("Experimente agora", "Estrelar o repositório", "Inicie seu teste gratuito")
3. Opcionalmente, termine com uma declaração prospectiva ou pergunta para estimular discussão

Conteúdo visual

Gere diretamente quando possível:

• Diagramas de arquitetura → blocos de código mermaid ou SVG inline
• Diagramas de fluxo de dados → blocos de código mermaid
• Tabelas de comparação → tabelas markdown
• Exemplos de código → blocos de código com destaque de sintaxe

Para imagens que precisam de criação externa:

<!-- TODO: Adicionar imagem aqui -->
<!-- Sugestão: [descrição do que a imagem deve mostrar] -->
<!-- Prompt LLM: "[prompt pronto para uso para um modelo de geração de imagem, ex.: 'Uma ilustração limpa e minimalista mostrando um painel com alternância de modo escuro, estilo de design plano, estética de ferramenta de desenvolvedor, proporção 16:9']" -->
![Descrição do texto alternativo](placeholder.png)

Use visuais sempre que ajudarem na compreensão - após explicar um conceito complexo, ao comparar opções ou ao mostrar mudanças de UI.

Exemplos de código

Para públicos de desenvolvedores, inclua pelo menos um exemplo de código mostrando a funcionalidade em ação. Prefira trechos mínimos e executáveis (5-15 linhas). Mostre antes/depois ao demonstrar uma melhoria.

Fase 5b: Revisão do Rascunho Completo

Após todas as seções serem escritas e a manchete selecionada, monte o post completo (frontmatter + corpo).

• Nível A: Pule a revisão. Prosiga diretamente para a saída. Apresente o post final e salve. O usuário pode solicitar alterações depois.
• Nível B: Apresente o rascunho completo ao usuário para revisão antes de salvar. "Aqui está o post completo. Quer alguma alteração antes de eu salvá-lo?"
• Nível C: O usuário viu cada seção individualmente, mas ainda assim apresente o rascunho montado para uma revisão final. "Aqui está o post completo. Quer alguma alteração antes de eu salvá-lo?"

Para B e C, se o usuário solicitar revisões, faça-as e apresente novamente. Prossiga para a saída apenas após o usuário aprovar.

Fase 6: Saída

Detecte o diretório de blog existente primeiro. Verifique por:

• content/blog/, src/pages/blog/, _posts/, blog/, posts/, articles/

Se encontrado, use esse diretório. Se não, use como padrão blog/posts/.

Apresente ao usuário:

"Vou salvar isso em [caminho-detectado-ou-padrão]/<slug>.md. Quer em outro lugar, ou devo pular o salvamento e apenas imprimir?"

Crie o diretório se não existir.

Se o arquivo já existir: pergunte se deve sobrescrever ou criar uma cópia versionada.

Tratamento de Erros

• gh não disponível → informe o usuário, ofereça entrada alternativa
• PR/ref inválido → peça ao usuário para verificar
• Nenhum contexto do produto → peça ao usuário para descrever o produto
• WebSearch não disponível → pule a Fase 2, prossiga com conhecimento próprio
• Nenhum diretório de blog existente → use blog/posts/ como padrão, crie-o

O que esta skill NÃO faz

• Gera conteúdo para redes sociais (use /social-copy para isso)
• Publica ou implanta o post em qualquer plataforma
• Gera briefings de marketing (use /marketing-brief para isso)
• Cria várias variantes para diferentes públicos - execute a skill novamente para um público diferente