Até essa semana, publicar um post no meu próprio canal do LinkedIn significava colar um trecho de material bruto num painel local e gerar um rascunho por vez. Funcionava, mas era trabalho manual repetido cinco vezes por semana. Troquei isso por uma automação, mas a parte que valeu a pena registrar não foi a automação em si.
O problema real
Eu já tinha o painel: Flask + SQLite, guarda rascunho com status ideia, aprovado ou postado, nunca publica sozinho. O que faltava era a parte chata: eu precisava ir buscar o material real (o que eu tinha construído, decisões técnicas, números verificáveis) e colar manualmente antes de cada geração. Sem material colado, o gerador certo se recusava a inventar um caso, o que é correto, mas isso não resolvia o trabalho de garimpar o material.
O que construí
Uma skill de linha de comando que faz esse garimpo sozinha: lê o histórico técnico real de um projeto, pega os posts que eu já aprovei antes como referência de padrão, e gera o lote do período (uma semana, por exemplo) já formatado, salvando tudo como rascunho pendente de aprovação no mesmo banco que o painel já lia.
Decisão técnica: genérica desde o primeiro uso
A decisão que importa não foi a geração de texto, foi a forma. Em vez de escrever algo específico para esse canal, cada canal que eu queira automatizar ganha sua própria pasta de configuração: de onde vem o material real, que regras de tom seguir, que formato aceitar. A automação resolve o pedido contra essas configurações antes de gerar qualquer coisa.
Se eu pedir um canal que ela não reconhece, ela não improvisa uma configuração plausível. Ela para e me pergunta. O custo de perguntar uma vez é menor que o custo de uma automação decidindo sozinha um padrão de voz errado e eu só descobrir isso lote de conteúdo adentro.
A segunda regra, essa não é nova, só herdada do painel: nada é publicado sozinho. Todo item nasce como rascunho. LinkedIn proíbe automação de conta pessoal nos termos de uso, e essa conta é justamente o canal que uso pra buscar vaga — não é o lugar pra testar automação agressiva.
Como verifiquei
Não troquei a estrutura do banco sem checar o que já existia nele. Antes de mudar o schema, rodei a migração contra o banco real (não uma cópia vazia) e conferi que o registro que já estava lá continuava intacto depois. Testei inserir, listar e apagar um item de teste, e só depois disso abri o painel no navegador pra confirmar visualmente que a mudança aparecia como esperado, antes de remover o dado de teste.
No mesmo processo, ao ir escrever a documentação da automação, encontrei uma divergência que não tinha nada a ver com ela: a ficha de um projeto meu ainda descrevia um plano de semanas atrás que eu nunca tinha executado de verdade, porque o plano real tinha mudado de rumo sem ninguém atualizar o registro. Corrigi a documentação para bater com o que realmente existe, em vez de deixar duas versões da mesma decisão competindo — e virou a mesma regra que apliquei na automação nova: o que está escrito precisa bater com o que está rodando, ou vira ruído.