Pipeline de blog
O que você obtém: um post que responde a uma busca real, no seu tom de voz, com fatos verificados, uma imagem de 1200×630 e frontmatter válido, aguardando sua revisão em sua própria pasta.
Primeira coisa a fazer: coloque um BLOG.md preenchido na raiz do seu projeto (o modelo está neste repositório). Cada estágio o lê.
Leia primeiro, sempre
BLOG.mdna raiz do projeto: site, leitor, objetivo, tom, palavras a evitar, categorias, cadência, regras de SEO e imagem, padrões de frontmatter e a lista de Correções. Onde BLOG.md e esta skill discordarem, BLOG.md vence.references/frontmatter-contract.mdantes de escrever qualquer frontmatter.- O arquivo de referência para o estágio em que você está executando, e nada mais que não precise.
Ainda não tem BLOG.md? Pare e ofereça-se para criar um. Leia de 3 a 5 dos posts ou páginas existentes da pessoa, faça as perguntas de cada seção do modelo, escreva o arquivo e peça para ela verificar. Um post escrito sem ele soa como ninguém em particular.
Como funciona
Um post de blog é a resposta a algo que uma pessoa digita no Google. O conhecimento pode vir de uma palestra, uma newsletter ou uma chamada de cliente; o post o reconstrói em torno de uma busca: um título que corresponda à busca, a resposta perto do topo, cabeçalhos fraseados do modo como as pessoas buscam.
Atualize antes de escrever algo novo. Verifique se um post ou página existente já tem como alvo a busca. Um post que o Google já mostra, com visualizações e sem cliques, vale mais do que um post novo do zero, e exige uma fração do trabalho. Duas páginas visando a mesma busca geralmente perdem ambas.
A pasta de trabalho
Uma pasta por post, no projeto da pessoa: posts/<YYYY-MM-DD>-<slug>/. A data é o dia planejado de publicação. O slug é o endereço final e o nome do arquivo. Cada estágio escreve um arquivo na pasta, então a pasta é a memória: qualquer estágio pode ser executado novamente ou retomado depois sem refazer os estágios anteriores.
| # | Estágio | Lê | Escreve | Instruções |
|---|---|---|---|---|
| 1 | Ideação | BLOG.md, dados de busca, posts e páginas existentes | posts/_ideas/topic-ideas.md | references/01-ideation.md |
| 2 | Briefing | um tópico | brief.md | references/02-brief.md |
| 3 | Pesquisa | brief.md | research.md | references/03-research.md |
| 4 | Rascunho | research.md, brief.md, BLOG.md | draft.md | references/04-draft.md |
| 5 | Visuais | draft.md | visuals.md, <slug>.svg, <slug>.png | references/05-visuals.md |
| 6 | Publicação | draft.md, visuals.md | o post em src/content/blog/, imagens em public/images/blog/, publish.md | references/06-publish.md |
A cadeia completa: estágios 2 a 6 em ordem para um tópico. O estágio 1 é uma etapa em lote: execute-o quando a lista de ideias estiver baixa, cerca de uma vez por mês em uma cadência semanal.
"Planeje meu primeiro post" (ou "planeje meu próximo post"): estágio 1, depois estágio 2. Execute a ideação, mostre a lista reduzida, deixe a pessoa escolher um tópico (não precisa ser o nº 1; registre a escolha e o motivo em topic-ideas.md), depois escreva seu briefing. Pare após o briefing e diga qual estágio vem a seguir. Quando a pessoa pedir para "encontrar ideias de tópico", execute apenas o estágio 1; quando pedir para "escrever o briefing para <tópico>", execute apenas o estágio 2.
Um estágio: a pessoa nomeia o estágio e o post. Leia o arquivo desse estágio e suas entradas, e pule o resto.
Uma atualização: pule os estágios 1 e 2. Crie a pasta posts/<hoje>-<slug>-refresh/, execute os estágios 3 e 4 em modo de atualização, depois o estágio 6.
Os caminhos acima são os do site inicial. Se BLOG.md listar outras pastas, use essas.
Regras
Estas substituem qualquer arquivo de estágio. BLOG.md pode adicionar mais.
- Nunca invente uma fonte, estatística, citação ou link. Toda URL em um post foi aberta durante a pesquisa. Uma afirmação que você não pode verificar é cortada, ou marcada como
[NÃO VERIFICADO]para a pessoa confirmar. A experiência da própria pessoa conta como fonte quando é rotulada como dela. Um número do trabalho dela precisa de um arquivo no projeto ou de uma citação de chat datada registrada emresearch.md(estágio 3); sem um, é[NÃO VERIFICADO]e fica fora do arquivo publicado. - Verifique fatos sobre ferramentas e plataformas na documentação atual. Recursos e limites mudam, e o passo a passo do ano passado geralmente está errado hoje.
- Números de busca são dados ou são rotulados. Volume e dificuldade vêm de uma ferramenta que alguém executou, com a data, ou o arquivo diz "não estimado". Um número adivinhado apresentado como dado é pior do que nenhum número.
- A pessoa revisa todo rascunho antes de publicar. Posts novos recebem
draft: true. A skill nunca envia, implanta ou alteradraftpor conta própria. A única exceção é uma atualização de um post ao vivo, que mantémdraft: false(veja o estágio 6). - Aprovação: quando, como e onde as edições vão. Este é o único lugar onde a skill a define; o estágio 6 a segue.
- Quando: a qualquer momento após o estágio 6 ter escrito o arquivo publicado e a pessoa ter lido o post. A mesma sessão é aceitável.
- Como: uma alteração. A pessoa define
draft: falseemsrc/content/blog/<slug>.md, ou diz ao Claude para fazer isso. Confirme quedateé o dia de publicação ao mesmo tempo. - Onde as edições vão: antes do estágio 6, em
posts/<pasta>/draft.md. Após o estágio 6, apenas no arquivo publicado.draft.mdpermanece como o rascunho que foi entregue, epublish.mdlista cada alteração feita depois dele. - O que o retém: qualquer coisa ainda a fazer antes da data (uma página faltando, uma afirmação
[NÃO VERIFICADO], uma linha que a auditoria de links imprime) mantém o post comodraft: trueaté que esteja concluído.
- A data é o portão de publicação. O starter mantém um post com data futura oculto até seu dia e o lista em Posts Futuros.
- Trabalho de cliente permanece anônimo a menos que o cliente tenha concordado em ser nomeado. Remover o nome é o começo: verifique combinações de categoria, local e momento que ainda o identifiquem ("uma loja de velas em Vermont que lançou em março" é um nome). Transforme receita em proporções ou porcentagens.
- Responda primeiro. Um compasso de contexto que o leitor reconheça de seu próprio trabalho, depois a resposta até o final do terceiro parágrafo. Uma pergunta nunca abre um post.
- Escreva para a busca, com uma chamada para ação. Cabeçalhos fraseados do modo como as pessoas buscam, numerais para números, parágrafos curtos. A ação principal é a da seção 3 do BLOG.md, e corresponde a
ctaemsrc/site.config.mjs. O starter mostra esse botão, com uma caixa de inscrição, no final de cada post, então o corpo não precisa de um link de chamada para ação de encerramento. O corpo pode vincular à ação principal uma vez, no texto, apenas onde se encaixa no post, e apenas para uma página que existe ou para o endereçocta. - Vincule apenas a páginas que estão ao vivo na data de publicação do post. Isso significa cada link para o próprio domínio do site, posts e páginas igualmente. Escreva links para o próprio site como links relativos (
/about/). O estágio 6 tem a verificação. - A voz pertence à pessoa. Um rascunho que parece conteúdo competente de um estranho falhou, mesmo quando todas as regras passam.
Correções se tornam regras
Quando a pessoa corrige a mesma coisa duas vezes (uma palavra, uma abertura, um estilo de cabeçalho), ofereça-se para adicionar uma linha datada à seção de Correções do BLOG.md. O estágio 4 lê essa seção antes de todo rascunho, então uma correção feita uma vez permanece corrigida.
Antes de entregar um rascunho
Pesquise no rascunho por cada palavra na seção "Palavras a evitar" do BLOG.md, por exemplo:
grep -n -i -E "palavra um|palavra dois|—" posts/<pasta>/draft.md
Uma busca por palavras perde formas de frase. Execute a busca por formas no estágio 4 ("Formas que uma busca por palavras perde"), depois leia o rascunho uma vez para as formas que BLOG.md lista e que nenhuma busca captura, como uma pergunta de abertura ou um resumo de encerramento. Verifique também cada frase factual com research.md (estágio 4).
Depois, diga à pessoa, em poucas linhas: onde está o rascunho, a busca alvo, a data planejada, qualquer coisa marcada como [NÃO VERIFICADO], qualquer questão de confidencialidade, e o que ela precisa decidir.
Opcional: uma versão para newsletter
Se a pessoa também publica uma newsletter (Substack, Beehiiv, Kit ou similar), o mesmo conhecimento pode ir para lá. Dê à versão da newsletter seu próprio título e sua própria frase de busca, para que as 2 páginas não concorram no Google, e adicione o arquivo da newsletter à verificação de sobreposição nos estágios 1 e 2.
Ferramentas
Claude Code, ou Claude com acesso aos arquivos do projeto. Os dados de busca vêm de ferramentas gratuitas: autocomplete do Google, Google Search Console, o plano gratuito do Ubersuggest e uma busca simples no Google pela primeira página. Se uma ferramenta não estiver conectada, peça à pessoa que cole o que vê (Ubersuggest funciona bem em seu site), ou marque o número como não estimado. Um site novo sem dados e sem ferramentas ainda pode prosseguir: references/01-ideation.md tem o caminho.
Sem acesso à web nesta sessão: o estágio 1 classifica as ideias com base nas evidências que tem e marca o resto como "não verificado". A pessoa cola as sugestões de autocomplete e a primeira página para a única busca alvo que escolheu, no estágio 2, antes de o briefing ser aprovado. Ninguém cola para toda a lista reduzida. Mantenha chaves de API fora do BLOG.md e das pastas de post.