Projeto final: o skill /plan-week

Vamos juntar tudo

Tens agora todas as peças: um skill de criação (cap. 3), uma voz de marca (cap. 4), um quality gate automático (cap. 5) e uma publicação paralela (cap. 6). Cada tijolo foi construído e testado isoladamente — é isso que torna a montagem serena. Vamos ligá-los num único comando que planeia uma semana inteira de conteúdo: /plan-week.

Mede o caminho percorrido com a Lea: no capítulo 1, ela descobria que um agente pode ler os seus ficheiros. Agora, prepara-se para escrever uma frase e obter sete dias de conteúdo multi-plataforma, na sua voz, verificado pela sua salvaguarda, agendado nos horários certos. Não é magia: é composição. Cada capítulo era uma função; este capítulo escreve o programa principal.

A arquitetura antes do código

Antes de criar o skill, compreende o seu fluxo — porque és tu que terás de o depurar se algo encravar. O comando encadeia cinco fases: pesquisa do tema, geração de um plano escrito num ficheiro, pausa de validação humana, execução paralela por subagents, e registo. A pausa no meio não é uma concessão: é o ponto de arquitetura mais importante do capítulo.

flowchart LR
  A["Tema"] --> B["Pesquisa"]
  B --> C["content-plan.md"]
  C --> D{"Validação humana"}
  D -->|"A corrigir"| C
  D -->|"OK"| E["Subagents em paralelo"]
  E --> F["Posts agendados + registo"]

Repara onde está colocada a validação: depois da produção do plano completo (o trabalho longo e fastidioso já está feito), mas antes de qualquer ação irreversível (nada foi ainda publicado nem agendado). É a colocação ótima do controlo humano: relês um documento acabado, confortavelmente, e a tua decisão incide sobre algo concreto. Validar demasiado cedo (sobre uma intenção vaga) não controla nada; validar demasiado tarde (depois da publicação) já não serve de nada.

Criar o skill /plan-week

cria um skill "plan-week" que:
- aceita um tema, rascunhos, URLs ou imagens
- pesquisa o tema e escreve um plano semanal em content-plan.md (dia, n.º do post, tema, texto completo, visual sim/não)
- o texto deve ser o post completo bem formatado, não um resumo, adaptado por plataforma
- cria o visual uma vez por dia (reutilizado pelos posts do dia)
- mostra-me o plano e pede validação
- após validação, usa subagents paralelos para agendar cada post
- reutiliza a voz, a configuração e o registo do skill /post

faz-me perguntas uma de cada vez até 95% de confiança.

Duas linhas deste prompt merecem a tua atenção. «O texto deve ser o post completo, não um resumo»: sem esta precisão, obterias um plano de temas — bonito mas inutilizável, porque ainda terias de redigir tudo. «Reutiliza a voz, a configuração e o registo do skill /post»: é a composição em ação. O novo skill não reinventa nada, apoia-se nos tijolos existentes — daí o interesse de ter centralizado a voz no brand-voice.md no capítulo 4.

O ficheiro como interface de trabalho

O Claude pesquisa o tema, gera o content-plan.md e pede o teu acordo. Esta escolha — um ficheiro em vez de uma longa mensagem na conversa — é uma prática a reter para todos os teus futuros sistemas. Um ficheiro relê-se tranquilamente, edita-se diretamente, versiona-se no Git e sobrevive à conversa.

# Plano de conteúdo — semana de 17 de junho

## Segunda — Post 1 (LinkedIn)
Tema: porque é que o «sem perfume» é um falso amigo
Visual: sim (infografia ingredientes)
Texto:
> Pensamos estar a fazer bem ao escolher «sem perfume»...
> [post completo, pronto a publicar]

## Segunda — Post 2 (Twitter)
...

Tu relês; se um rascunho não estiver bem, editas diretamente o ficheiro — não precisas de descrever a modificação ao Claude, corriges o texto tu mesmo como em qualquer documento — e depois dizes «continua». O Claude retoma o ficheiro no seu estado atual e lança um subagent por post, em paralelo. O ficheiro é a interface; a conversa é apenas o gatilho.

Quando descarrila: depurar uma orquestração

Com um sistema que encadeia cinco fases, é preciso saber localizar uma avaria. O método é sempre o mesmo: identificar a fase que produziu o problema, e corrigi-la isoladamente. O plano está fora do tema? É a fase de pesquisa — precisa o briefing ou as fontes no skill. Os textos são bons mas o tom desvia-se? É o brand-voice.md que é preciso enriquecer (capítulo 4). Um post está bloqueado no agendamento? Lê a mensagem do quality gate (capítulo 5). Uma única rede falha? É o subagent ou a API dessa plataforma (capítulo 6).

Reparas no reflexo: cada tijolo do curso é também uma zona de diagnóstico. É a vantagem decisiva de ter construído o sistema peça a peça em vez de num só bloco — sabes onde olhar, e podes testar cada peça separadamente com os comandos dos capítulos anteriores.

O padrão a reter: melhora a ferramenta, não o resultado

Continuas ao comando: validas o plano antes de qualquer execução. A IA e a automatização gerem o trabalho repetitivo. E quando a diferença entre o que querias e o que o Claude produziu for grande, não te limites a corrigir o ficheiro: diz-lho — e pede-lhe para atualizar o skill para que a próxima vez seja melhor.

Concretamente, depois de cada execução do /plan-week, faz a pergunta: «o que corrigi à mão no plano?» Cada correção manual recorrente é uma regra que falta ao skill. Três semanas deste reflexo e as tuas correções manuais tendem para zero — é mensurável, e é o critério objetivo de um sistema maduro.

O que este projeto final te ensinou realmente

Para além do marketing da Lea, acabaste de executar um esquema universal de automatização: decompor um processo de negócio em etapas, codificar cada etapa (skill), securizar o inegociável (hook), paralelizar o independente (subagents) e colocar a validação humana no ponto de alavancagem máxima. Substitui «posts» por «faturas a relançar», «tickets de suporte a triar» ou «monitorização da concorrência a resumir»: o esquema mantém-se tal e qual.

Resta uma fragilidade: todo este conhecimento vive em ficheiros, mas o Claude recomeça do zero a cada sessão e tem de os redescobrir. O último capítulo resolve isso — e é ele que transforma uma bela demonstração num sistema duradouro.