Newsletter Writer

O que Newsletter Writer faz?

Escreva e-mails de atualização de produto e newsletters de anúncio de funcionalidades. Lida com linhas de assunto, texto de pré-visualização, estrutura do e-mail e conteúdo adequado ao público.

Resolução da Entrada

Resolva o argumento (se fornecido) nesta ordem:

1. Caminho para um resumo de marketing existente (.md contendo "Sumário Executivo" ou "Mensagens-Chave") -> resumo de marketing
2. Caminho para uma postagem de blog existente (.md com estrutura de postagem de blog) -> postagem de blog
3. Caminho para um changelog existente (.md com seções Adicionado/Corrigido/Alterado ou CHANGELOG.md) -> changelog
4. Corresponde a URL do GitHub ou padrão #\d+ -> PR
5. Contém ... ou .. -> intervalo de referências Git
6. Resolve para arquivo/diretório existente -> funcionalidade do codebase
7. Caso contrário -> texto livre

Se nenhum argumento for fornecido, pergunte: "O que a newsletter deve cobrir? Você pode fornecer um resumo de marketing, postagem de blog, changelog, URL/número de PR, intervalo de referências Git, caminho de arquivo/diretório ou apenas descrever a atualização."

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

Fluxo do Processo

digraph newsletter {
    rankdir=TB;
    "Resolver entrada" [shape=box];
    "Fase 1: Descoberta" [shape=box];
    "Fase 2: Configuração" [shape=box];
    "Fase 3: Escrita" [shape=box];
    "Fase 4: Revisão" [shape=box];
    "Aprovado?" [shape=diamond];
    "Fase 5: Saída" [shape=box];

    "Resolver entrada" -> "Fase 1: Descoberta";
    "Fase 1: Descoberta" -> "Fase 2: Configuração";
    "Fase 2: Configuração" -> "Fase 3: Escrita";
    "Fase 3: Escrita" -> "Fase 4: Revisão";
    "Fase 4: Revisão" -> "Aprovado?";
    "Aprovado?" -> "Fase 3: Escrita" [label="revisões"];
    "Aprovado?" -> "Fase 5: Saída" [label="sim"];
}

NÃO pule fases. Faça perguntas em um ritmo natural. Se o usuário responder várias perguntas de uma vez, aceite respostas agrupadas e avance.

Se o usuário disser "só use padrões", "você escolhe" ou similar, escolha padrões razoáveis baseados no contexto, informe o que escolheu e peça uma única confirmação antes de prosseguir.

Nunca presuma sem confirmar.

Fase 1: Descoberta

Etapa 1 - Analise a entrada

Tipo de entrada	O que ler
Resumo de marketing	Extraia declaração do problema, proposta de valor, público, mensagens-chave. Pule para a Etapa 3. Ainda faça a Etapa 2 se o resumo não tiver contexto do produto.
Postagem de blog	Extraia título, pontos principais, público, CTA. Pule para a Etapa 3. Ainda faça a Etapa 2 se não tiver contexto do produto.
Changelog	Extraia todas as entradas. Use como base para um e-mail digest. Pule para a Etapa 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.
Referências Git	git diff e git log entre referências. Para intervalos grandes, priorize mensagens de commit e mudanças voltadas ao usuário.
Funcionalidade do codebase	Leia os arquivos/diretórios especificados.
Texto livre	Analise a descrição do usuário. Se faltar especificidade, peça ao usuário mais detalhes ou aponte para um arquivo/PR específico. Recurso a perguntas abertas apenas se não for possível.

Mudanças voltadas ao usuário incluem: novas funcionalidades, mudanças na interface, mudanças na API, melhorias de performance, correções de bugs e atualizações de documentação. Mudanças internas incluem: refatorações, adições 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 disponível -> informe o usuário, sugira gh auth login, ofereça entrada alternativa
• PR/ref inválido -> peça ao usuário para verificar
• Arquivo não encontrado -> peça o caminho correto

Etapa 2 - Leia o contexto mais amplo do produto

Leia, se existirem: README, docs/, package.json (ou equivalente).

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

Etapa 3 - Apresente o entendimento e determine o formato

Apresente um resumo estruturado:

"Aqui está a base para a newsletter:"

• Atualização A - breve descrição
• Atualização B - breve descrição

"Algo para adicionar, remover ou corrigir?"

Em seguida, determine o formato do e-mail com base no número de atualizações:

• Atualização única importante -> e-mail de funcionalidade única (focado, aprofundado)
• Múltiplas atualizações -> e-mail digest (lista priorizada, a mais importante expandida)

Confirme o formato com o usuário.

Se nenhuma mudança voltada ao usuário for encontrada na entrada, informe o usuário e pare: "Nenhuma mudança voltada ao usuário encontrada nesta entrada. Não há o que escrever em uma newsletter."

NÃO prossiga até que o usuário confirme o escopo e o formato.

Fase 2: Configuração

Faça estas perguntas:

P1 - Público: "Para quem este e-mail vai?" (todos os usuários, usuários avançados, novos usuários, plano específico, desenvolvedores, usuários não técnicos, outro)

P2 - Formato de saída: "Em qual formato você quer o e-mail?"

• Apenas cópia - linha de assunto, texto de pré-visualização, corpo do texto, texto do CTA (para inserir na sua ferramenta de e-mail)
• Markdown - markdown formatado que a maioria das ferramentas de e-mail pode importar

P3 - Tom: Leia o conteúdo existente do repositório (README, docs, postagens de blog) para detectar a voz do produto. Depois confirme:

"Com base no seu conteúdo existente, o tom parece [por exemplo, conversacional e amigável para desenvolvedores]. Devo manter esse tom ou seguir um direcionamento diferente?"

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

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

• Nova funcionalidade -> "Experimente agora", "Veja o que há de novo"
• Melhoria -> "Confira", "Veja a diferença"
• Open source -> "Atualize agora", "Veja o lançamento"

"Sugiro que o CTA seja: [CTA inferido]. Quer seguir com isso ou algo diferente?"

Fase 3: Escrita

Linhas de assunto

Gere 3-5 opções de linha de assunto com diferentes abordagens:

• Baseada em benefício ("Seus relatórios agora exportam para PDF")
• Curiosidade ("Reconstruímos como a busca funciona")
• Nome da funcionalidade específica ("Apresentando o modo escuro")
• Pergunta ("Ainda esperando as exportações terminarem?")
• Urgência/tempestividade ("Novo esta semana: 3 funcionalidades que você pediu")

Recomende uma e explique por que ela funciona melhor. Também explique as vantagens e desvantagens das outras.

Regras:

• 30-50 caracteres ideal (evite truncamento no celular)
• Seja específico, não genérico ("Novo: Exportações para PDF" vence "Atualização de Produto - Março de 2026")
• Sem palavras-gatilho de spam (Grátis, Compre Agora, Aja Agora)

Texto de pré-visualização

Gere texto de pré-visualização para cada opção de linha de assunto. O texto de pré-visualização é a linha secundária visível nas prévias da caixa de entrada.

Regras:

• 40-130 caracteres
• Expanda a linha de assunto, não a repita
• Inclua o benefício ou resultado principal

Corpo do e-mail

Estrutura de e-mail de funcionalidade única:

1. Declaração do problema - uma frase descrevendo o ponto de dor que esta funcionalidade resolve
2. O que mudou - 2-3 frases descrevendo a atualização em linguagem de benefício para o usuário ("Relatórios carregam mais rápido" não "Consulta SQL otimizada")
3. Placeholder visual - <!-- TODO: Adicionar captura de tela ou GIF mostrando a funcionalidade em ação --> com uma descrição do que capturar
4. Botão CTA - ação única e clara

Estrutura de e-mail digest:

1. Atualização principal - a atualização mais importante recebe o tratamento completo de funcionalidade única (problema, o que mudou, visual, CTA)
2. Atualizações secundárias - balas breves com descrições de uma linha e links
3. Correções rápidas / melhorias - lista agrupada de mudanças menores
4. CTA de encerramento - ação única ou "Veja todas as atualizações"

Regras de escrita

• Comece pelo benefício para o usuário, não pelo que você construiu
• Tom conversacional, não corporativo
• Parágrafos curtos (máximo 2-3 frases)
• Uma ideia por parágrafo
• Nunca use travessões no conteúdo gerado. Nada de caracteres "---". Use vírgulas, dois pontos, pontos ou parênteses.
• Sem jargão. "Relatórios carregam mais rápido" vence "Plano de execução de consulta SQL otimizado"
• Negrito nas frases-chave para facilitar a leitura dinâmica
• Mantenha escaneável. Mais curto é melhor. Se o e-mail leva mais de 60 segundos para ler, é muito longo.

Variantes de segmento

Após gerar o e-mail principal, pergunte:

"Quer que eu gere variantes para diferentes segmentos de público? (por exemplo, uma versão mais técnica para desenvolvedores, uma versão mais simples para usuários não técnicos)"

Se sim, gere as variantes solicitadas, ajustando tom, profundidade e ênfase das funcionalidades por segmento.

Fase 4: Revisão

Apresente o e-mail completo:

"Aqui está a newsletter:"

Opções de linha de assunto: (com recomendação e texto de pré-visualização para cada)

1. Assunto: "..." / Pré-visualização: "..."
2. Assunto: "..." / Pré-visualização: "..."
3. Assunto: "..." / Pré-visualização: "..."

Corpo: [conteúdo completo do e-mail]

"Escolha uma linha de assunto e me avise se quiser alguma alteração."

Aguarde o usuário selecionar uma linha de assunto e aprovar ou solicitar revisões. Só prossiga para a saída após a aprovação.

Fase 5: Saída

Sempre imprima o e-mail final aprovado no terminal.

Depois pergunte: "Quer que eu salve isto em emails/<slug>.md? Ou em um caminho diferente?"

Crie o diretório se não existir. Se o arquivo já existir, pergunte se deve sobrescrever ou criar uma cópia com versão.

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
• Sem contexto do produto -> peça ao usuário para descrever o produto
• Sem diretório de e-mails existente -> padrão para emails/, crie-o

O que este skill NÃO faz

• Enviar ou agendar e-mails
• Gerenciar listas de assinantes ou lógica de segmentação
• Criar templates de e-mail ou sistemas de design
• Gerar postagens de blog ou cópia para redes sociais (use /blog-post ou /social-copy)