Claude Code: checklist para provar com evidências que a tarefa terminou de verdade

Numa sexta à noite, pedi para o Claude Code: “escreve um artigo e leva até a publicação”. Aí fui dormir. Na manhã seguinte abri o log e lá estava, todo confiante: “Concluído. Artigo publicado.” Tranquilo, abri a URL pública e o que apareceu foi o título do artigo anterior.

O build tinha passado. A URL devolvia 200. Mas a tag h1 continuava sendo a de outra página. Eu tinha terceirizado a conferência do diff para a IA e estava acreditando só na palavra “funcionou”.

Foi aí que caiu a ficha: o que me derrubou não foi a inteligência do Claude Code, foi o meu jeito de “fechar a tarefa”. Quanto mais escopo você delega para a IA, mais precisa guardar com você mesmo a resposta de “o que de fato foi verificado”. Sem isso, você cai todo dia no mesmo relatório de conclusão mentiroso.

Neste artigo eu mostro esse “padrão de guardar evidências”, junto com código que você copia e cola.

Pontos principais

• Não acredite no “pronto” da IA. Só conte como prova de conclusão o que foi verificado por máquina: build, URL pública, h1 e CTA.
• Antes de começar a editar, decida em uma frase “o que esta tarefa precisa provar” e escolha o comando de verificação com antecedência.
• Depois de publicar, sempre confira na mesma ordem (h1 → canonical → início do texto → CTA). Ordem fixa reduz o que passa batido.
• Deixe a evidência (screenshot, URL, próxima métrica) anotada em uma linha. Assim, você de amanhã (ou a automação) não refaz a mesma decisão do zero.
• Mais forte que publicar um artigo perfeito de primeira é publicar um artigo que dá para verificar no dia seguinte.

Por que parar no “pronto” dá acidente

O Claude Code resume em texto o andamento da tarefa. E aí está o problema: o resumo volta com quase a mesma cara quando deu certo de verdade e quando não deu.

Build passou significa apenas “a sintaxe não está quebrada”. A URL pública devolver 200 significa apenas “o servidor devolveu alguma coisa”. Se essa alguma coisa é o artigo que você acabou de criar, isso é outra história.

No meu acidente de sexta, build e 200 estavam os dois ok. O que estava quebrado era um único ponto: se a URL e o conteúdo da página batiam. E ninguém estava olhando justamente isso.

Por isso a decisão de “concluído” não fica na palavra da IA, e sim no resultado de você ter eliminado um a um os itens que você mesmo definiu para conferir. Se a base do seu fluxo de conferência ainda é frágil, vale alinhar o passo a passo básico antes em como começar com o Claude Code. Aí os passos deste artigo encaixam melhor.

O loop de verificação que roda em 15 minutos

Se você confere com passos diferentes a cada vez, num dia corrido vai pular alguma coisa, garantido. A ideia é fixar a ordem para rodar no automático, sem precisar pensar.

1. Escreva em uma frase “o que precisa estar verificado para considerar concluído”. Exemplo: “que o artigo deste slug está na URL pública com o h1 correto”.
2. Antes de começar a editar, defina os comandos da conferência (build, exibir diff). Não saia procurando depois que terminou.
3. Ao alterar, olhe na ordem diff → build → URL pública. Mesmo que você mude de ideia no meio, não quebre essa ordem.
4. Na URL pública, olhe com os olhos se h1, canonical, início do texto e CTA aparecem na ordem esperada.
5. Anote em uma única linha o risco que sobrou e “a menor próxima ação”.

O ponto aqui é separar logo no começo o que dá para delegar à IA e o que a pessoa decide.

Etapa	Pode delegar à IA	A pessoa julga
Escolha do tema	Ler títulos existentes e sugerir candidatos	Qual de fato escrever
Redação	Rascunho de texto, código e títulos	Se não entrou mentira ou informação velha
Verificação	Rodar o build, resumir o diff	Conferência final se o conteúdo da URL pública está correto
Publicação	Executar o comando de publicação	Aprovar operações irreversíveis, como apagar ou aplicar em produção

Só as operações irreversíveis, no começo, deixe todas em “pergunta para a pessoa”. Depois você promove para automático aquelas que se mostraram seguras. Essa lógica de onde traçar a linha está organizada em detalhe no guia de permissões.

Um modelo de pedido pronto para copiar e colar

Se você descreve a verificação do zero toda vez, vão faltar itens conforme o humor do dia. Deixar o texto que você passa para o Claude Code em formato de molde mantém os itens de conferência estáveis.

Publiquei este artigo. Antes de me dar o relatório de conclusão, confira o seguinte e responda em forma de tabela.
- O build teve sucesso? (escreva também o comando e o exit code)
- O h1 da URL pública bate com o título do artigo deste slug?
- O canonical aponta para o mesmo slug?
- O início do texto não é reaproveitamento do artigo anterior ou da home?
- O CTA (PDF grátis, material, consultoria) está na ordem que combina com a situação do leitor?
Nos itens que não conseguir confirmar, escreva "não confirmado", com honestidade. Não escreva "OK" por suposição.

A última frase é a que faz diferença. Se você não deixa explícito “não escreva OK por suposição”, a IA responde “sem problemas” com cara de aprovação até nos itens que não conferiu. Se você quer elevar o próprio jeito de montar o pedido, dê uma olhada também em engenharia de prompts avançada.

Script de verificação que roda quando você copia e cola

Aqui está o miolo de hoje. Ele vai buscar a URL pública e julga por máquina se o h1 é o título esperado. Roda só com Node.js (18 ou superior). Em vez do “pronto” da IA, use o veredito deste script como base da conclusão.

// verify-publish.mjs
// Uso: node verify-publish.mjs <URL pública> "<título h1 esperado>"
// Ex.: node verify-publish.mjs https://claudecode-lab.com/pt/blog/foo/ "Título do artigo"

const [url, expectedH1] = process.argv.slice(2);

if (!url || !expectedH1) {
  console.error("Passe os dois: a URL e o título h1 esperado.");
  process.exit(2);
}

// Busca a página publicada
const res = await fetch(url, { redirect: "follow" });
const html = await res.text();

// Extrai h1 e canonical de forma simples (não precisa de parser rigoroso)
const h1 = (html.match(/<h1[^>]*>(.*?)<\/h1>/is)?.[1] ?? "")
  .replace(/<[^>]+>/g, "")
  .trim();
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i)?.[1] ?? "";

// Elimina os itens de conferência um a um
const checks = {
  http200: res.status === 200,
  h1Bate: h1 === expectedH1,
  canonicalBate: canonical.includes(new URL(url).pathname),
};

console.table(checks);

const allOk = Object.values(checks).every(Boolean);
if (!allOk) {
  console.error("Há itens não confirmados ou divergentes. Não trate a publicação como concluída ainda.");
  console.error(`h1 obtido: ${h1 || "(vazio)"}`);
  process.exit(1);
}

console.log("Evidências reunidas. Pode tratar como concluído.");

Para executar é só isto.

node verify-publish.mjs https://claudecode-lab.com/pt/blog/foo/ "Título do artigo"

Se h1Bate der false, é exatamente o mesmo estado do meu acidente de sexta. A URL está viva, mas o conteúdo é outro. Enquanto o exit code não for 0, não chame a publicação de “concluída”. Só transformar isso em regra já barra o relatório de conclusão mentiroso antes que ele chegue até você.

Cenários em que isso ajuda

1. Publicação de artigos É o cenário em que a gente confunde só o HTTP 200 com sucesso. Com o script acima, se você confere que h1 e canonical apontam para o mesmo slug, derruba antes da publicação o reaproveitamento do artigo anterior ou o fallback para a home.

2. Troca do CTA Ao mexer no botão para o PDF grátis ou para o material, deixe o screenshot e a “próxima métrica” na mesma linha de anotação. Depois você consegue acompanhar se “aquela mudança aumentou os cadastros” pelo registro, não pela memória.

3. Mudança de configuração ou permissão É justamente quando você altera o CLAUDE.md ou as permissões que vale rodar o mesmo comando de verificação antes e depois. Se a forma de escrever a configuração ainda gera dúvida, alinhe primeiro como escrever o CLAUDE.md, e a base da verificação fica consistente.

Armadilhas e como corrigir

Sendo honesto, eu caí várias vezes nos mesmos buracos até chegar a esse padrão.

A primeira é tentar corrigir tudo numa tacada só e criar um diff grande demais para verificar. Um diff que mexe em 40 arquivos nem a pessoa nem a IA conseguem ler até o fim. A correção é simples: reduza a uma frase o que vai conferir numa única tarefa. Se ficar grande demais para conferir, divida o trabalho.

A segunda é tratar como concluído no momento em que o build local passou. Rodar localmente e aparecer corretamente na URL pública são coisas diferentes. A correção é rodar o script acima sempre uma vez, depois de publicar. Até eu colocar isso no fluxo, publiquei várias vezes conteúdo errado.

A terceira é só aumentar a quantidade de CTAs sem explicar para onde o leitor deve seguir. Enfileirar 3 botões não adianta se a pessoa não consegue escolher. A correção é, no próprio texto, dizer em uma frase qual CTA combina com cada situação do leitor (ainda inseguro com os comandos / cansado do trabalho repetitivo / pensando em adoção pela equipe).

Perguntas frequentes

Q. Se o build passou, já está concluído, não? O build é só prova de que a sintaxe não está quebrada. Se o conteúdo da URL pública é o artigo desta vez é outra questão. Só está concluído quando você olha até o h1 e o canonical.

Q. Tenho que rodar o script de verificação na mão toda vez? No começo, na mão basta. Quando o fluxo estabilizar, evolua para ele rodar automaticamente logo após o comando de publicação. Se o exit code não for 0, pare a publicação: com essa operação, os acidentes diminuem.

Q. Não pode delegar a verificação inteira para a IA? Ler e resumir, pode delegar. Mas o julgamento final de “se o conteúdo da URL pública está correto” e a aprovação de operações irreversíveis ficam com a pessoa. Se você entrega isso, não sobra ninguém para barrar o relatório de conclusão mentiroso.

Q. Quem não é da área de engenharia consegue rodar essa conferência? Consegue. O script roda copiando e colando, e o passo a passo visual é só decorar a ordem. Se o comando em si gera insegurança, comece pela explicação para quem não é da área, que fica mais tranquilo.

Q. O que basta deixar anotado? Bastam três coisas: “o que verifiquei desta vez”, “o risco que sobrou” e “a menor próxima ação”. Ata longa não precisa. O único objetivo é que você de amanhã não refaça a mesma decisão.

O que descobri testando na prática

Depois da publicação com conteúdo errado naquela sexta, troquei o critério de conclusão de “o que a IA disse” para “se o exit code do script é 0”.

Quando passei o verify-publish.mjs em umas 10 publicações de verdade, em 2 delas o h1Bate devolveu false. Ambas devolviam 200 e, batendo o olho, ninguém perceberia. Sem o script, eu teria publicado de novo a página reaproveitada.

Fixar a ordem do olhar visual também ajudou. Quando passei a conferir sempre na mesma sequência h1 → canonical → início do texto → CTA, aquele “opa, será que pulei isso de novo?” praticamente sumiu. Tirar o julgamento da cabeça e jogá-lo para o passo a passo deixou a conferência da noite bem mais leve, foi a sensação que tive.

Em vez de procurar a IA mais inteligente, coloque antes um mecanismo que percebe quando você tropeça. Parece volta maior, mas é o caminho mais rápido, essa é a minha conclusão hoje.

Se você já está no ponto de querer transformar esse padrão de verificação no padrão do time, ou de embuti-lo no fluxo de publicação da sua empresa, a gente desenha isso junto em treinamento e consultoria. A documentação oficial do Claude Code você confere na documentação da Anthropic.