Transformando Atividades Semanais do GitHub em Posts de Blog no Notion e DEV.to

Esta é uma submissão para o Desafio Notion MCP

O que eu construí

A cada reunião de standup na segunda-feira, alguém pergunta: "No que você trabalhou na semana passada?" E toda segunda-feira, eu fico olhando para a tela tentando lembrar. Eu fiz o merge daquela PR na quarta ou na quinta? Aquele refatoramento foi no módulo de autenticação ou no pipeline? Quantos repositórios eu toquei?

Eu cansei desse momento em branco. Então eu construí DevNotion — um pipeline de 3 agentes alimentado por Mastra que coleta toda a minha atividade semanal no GitHub, narra isso em um post de blog em primeira pessoa usando o Gemini e publica no Notion (como uma página estilo planejador com tabelas estruturadas) e no DEV.to (como um artigo rascunho). Todo domingo, automaticamente, via GitHub Actions.

Chega de amnésia de segunda-feira. O blog se escreve sozinho.

O que ele realmente faz

1. Coleta minha atividade no GitHub via GraphQL — commits, PRs, issues, revisões de código, discussões, estatísticas de linguagem, sequência de contribuições
2. Narra os dados brutos em um post de blog casual em primeira pessoa usando o Gemini (com um fallback determinístico se o LLM não estiver disponível)
3. Publica em duas plataformas simultaneamente:
   • Notion — uma página estilo planejador com tabelas de estatísticas, quebras de repositórios, tabelas de PR/issues/revisões, quebra de linguagem e o post completo do blog
   • DEV.to — um artigo rascunho pronto para revisão

Recursos principais

• 3 agentes especializados — cada um faz uma coisa bem (coletar, narrar, publicar)
• LLM apenas onde agrega valor — coleta e publicação são determinísticas, sem sobrecarga de tokens
• 4 perfis de tom de blog — casual (padrão), profissional, técnico, narrativa
• Páginas estilo planejador no Notion — não apenas uma parede de texto, mas tabelas estruturadas com estatísticas, repositórios, PRs, issues, revisões e linguagens
• Integração Notion MCP — toda a superfície da API do Notion via Protocolo de Contexto de Modelo
• API de Conteúdo Markdown do Notion — escreva markdown rico diretamente nas páginas (o verdadeiro divisor de águas)
• Publicação de rascunho no DEV.to — artigos criados como rascunhos, prontos para revisão e publicação
• CI de GitHub Actions — cron semanal (domingos 08:00 UTC) + despacho manual
• Registro de blog no README — CI auto-commita uma tabela de métricas após cada execução
• Cadena de fallback — sempre produz um post de blog, mesmo que o Gemini esteja fora do ar
• Limitação de taxa em todos os lugares — p-queue + p-retry para as APIs do Notion e DEV.to

Arquitetura

O pipeline usa um LLM apenas onde realmente agrega valor — na narração. A coleta e a publicação são chamadas de função puras. Sem sobrecarga de tokens, sem risco de alucinação, execução mais rápida.

Análise Profunda da Arquitetura

Por que 3 agentes, e não 1?

Eu poderia ter construído um mega-agente que faz tudo. Mas isso é uma receita para:

• Queimar tokens em trabalho determinístico (coletar dados do GitHub não precisa de um LLM)
• Alucinar URLs e estatísticas (o passo de publicação nunca deve inventar coisas)
• Pesadelos de depuração (qual parte do monólito falhou?)

Em vez disso, cada agente é um especialista. O fluxo de trabalho os encadeia:

export const weeklyDispatchWorkflow = createWorkflow({
  id: 'weekly-dispatch',
  inputSchema: z.object({ weekStart: z.string() }),
  outputSchema: PublishOutputSchema,
})
  .then(harvestStep)
  .then(narrateStep)
  .then(publishStep)
  .commit();

Três passos, encadeados com .then(), comprometidos como um único fluxo de trabalho. Mastra cuida da transferência de dados entre os passos automaticamente.

Coletar: dados determinísticos, zero LLM

O passo de coleta chama diretamente a API GraphQL do GitHub — nenhuma razão de agente necessária:

const harvestStep = createStep({
  id: 'harvest-github',
  inputSchema: z.object({ weekStart: z.string() }),
  outputSchema: WeeklyDataSchema,
  execute: async ({ inputData }) => {
    const data = await fetchWeeklyContributions(inputData.weekStart);
    return WeeklyDataSchema.