Como montei um pipeline para posts com críticos paralelos

Intenção

Eu queria expandir minha skill de escrita de posts. Me inspirei num artigo sobre content pipeline — lá se usa o formato de “documentação de conversas”, onde o autor mostra não só o resultado, mas o processo. Não queria copiar, queria criar um sistema modular:

• Pipeline de 5 fases com orquestração de agentes
• Integração com Exa AI para pesquisas
• Dois formatos de artigo (padrão e conversacional)
• Possibilidade de reusar a skill em diferentes sites

A ideia principal: em vez de passes sequenciais de edição, rodar agentes especializados em paralelo. Como o padrão fan-out/fan-in em sistemas distribuídos — distribuo o trabalho, coleto os resultados.

Tentativas

Primeira iteração: estrutura

Comecei criando uma estrutura modular:

/Users/ilya/.claude/skills/blogpost-pipeline/
├── phases/
│   ├── 01-questions.md
│   ├── 02-research.md
│   ├── 03-draft.md
│   ├── 04-critics.md
│   └── 05-deploy.md
├── formats/
│   ├── standard.md
│   └── conversation.md
└── config/
    ├── sites.yaml
    └── eo-os.yaml

Cada fase é um arquivo separado com instruções. Os formatos descrevem a estrutura do artigo. Os configs contêm as especificidades de cada site.

Segunda iteração: 5 fases

Desenhei o pipeline:

1. Questions — fazer perguntas ao usuário sobre tema, audiência, formato e site-alvo
2. Research — coletar material via Exa AI (semantic search) e busca na web
3. Draft — escrever o rascunho no formato escolhido
4. Critics — rodar 4 críticos em paralelo, coletar feedback, aplicar correções
5. Deploy — salvar no diretório correto, enviar prévia pelo Telegram

A quarta fase é diferente das demais. Em vez de um editor — 4 agentes especializados trabalham simultaneamente:

AI Slop Detector    ─┐
Rhythm Analyzer     ─┼─► Merge ─► Final edits
Specificity Checker ─┤
Fact Checker        ─┘

O AI Slop Detector procura clichês (“dive into”, “it’s worth noting”). O Rhythm Analyzer verifica o fluxo e a variação no comprimento das frases. O Specificity Checker substitui frases vagas por exemplos concretos. O Fact Checker exige comprovação para afirmações.

Todos os quatro olham para o mesmo texto em paralelo. Depois junto o feedback deles e faço as correções em uma única passagem. Se dois críticos se contradizem — resolvo manualmente.

Terceira iteração: configs dos sites

Criei configs para três sites no config/sites.yaml:

sites:
  igindin:
    path: apps/igindin-blog/drafts/
    telegram_channel: "@igindin_blog"

  t4s:
    path: apps/t4s-club/content/blog/
    telegram_channel: "@t4s_club"

  eo-os:
    path: apps/eo-os/content/articles/
    auto_publish: true

Uma skill lê o config e entende para onde salvar e como notificar.

Reviravoltas

Problema 1: skills duplicadas

Quando rodei a nova skill, apareceram dois comandos /blogpost na lista:

• Skill antiga (abordagem de 4 passes)
• Nova skill (pipeline de 5 fases)

Confusão. Apaguei a antiga:

rm -rf "/Users/ilya/[vibecoding]/.claude/skills/blogpost"

Problema 2: content-factory também era duplicata

Descobri que content-factory era uma versão antiga de funcionalidade similar. Apaguei ela também. Depois disso a lista de skills ficou limpa.

Problema 3: a skill não fazia perguntas

A primeira versão começava a escrever imediatamente, pulando a fase de perguntas. O resultado era um artigo sem contexto — 2000 palavras de frases genéricas tipo “AI é uma ferramenta poderosa”.

Adicionei no início do SKILL.md:

## CRITICAL: Start with Questions

**DO NOT start writing immediately.**

Before ANY writing, you MUST use AskUserQuestion to gather context:
1. Topic & angle
2. Audience
3. Format (standard/conversation)
4. Target site

Only after receiving answers → proceed to research and writing.

Agora a skill sempre começa com um diálogo. Os primeiros 2-3 minutos são perguntas, depois o resultado pronto logo na primeira tentativa.

Resultado

No final ficou um sistema funcional:

• Pipeline de 5 fases — de perguntas até o deploy
• Modularidade — formatos e configs são reutilizados
• Symlinks — uma skill em ~/.claude/skills/blogpost-pipeline/, symlinks em cada projeto
• Limpeza — sem duplicatas
• Perguntas obrigatórias — a skill não escreve às cegas

Rodo /blogpost, respondo 3-4 perguntas, recebo o artigo no formato certo para o site certo.

Conclusão

Críticos paralelos são fan-out/fan-in para texto.

A abordagem clássica de edição é sequencial: rascunho → estrutura → estilo → fatos → polimento final. Cada passe espera o anterior.

Nova abordagem: rascunho → [4 agentes simultâneos] → uma correção unificada. Mais rápido e mais completo, porque os agentes não se influenciam mutuamente e não ignoram problemas que “o anterior já corrigiu”.

Quando rodei os quatro críticos neste rascunho, eles encontraram:

• 7 lugares com palavras de hedging (“talvez”, “tipo”)
• 3 listas monótonas com itens de comprimento igual
• 5 afirmações abstratas sem exemplos
• 2 imprecisões técnicas

Manualmente eu teria levado 30-40 minutos em 4 passes. Os agentes paralelos fizeram isso em 2 minutos.

---

Este artigo foi escrito pela skill que ele descreve.