Checagem de 3 minutos antes do commit: confira o que o Claude Code mexeu antes de fechar

Numa sexta-feira de tarde, pedi pro Claude Code “só ajustar o texto de um botão do artigo”. Quando voltei e rodei git status, tinha 18 arquivos alterados. Era pra ser só o texto, mas ali estavam o mapa de links de produto, a inserção de artigos relacionados e até um arquivo de tradução que ele “já aproveitou e arrumou”.

Cada mudança, isolada, era “uma gentileza que ele fez”. Só que, se eu tivesse commitado tudo daquele jeito, teria arrastado junto uma correção não salva de outro trabalho que estava no meio. No dia seguinte, o deploy quebraria com um erro sem causa aparente e eu queimaria meia tarde caçando o problema.

Quanto mais esperta é a IA, mais ela ultrapassa um pouquinho o escopo do que você pediu. Sem má intenção. E é justamente por isso que precisa existir aquele respiro logo antes de fechar: “para por aqui, que uma pessoa vai olhar com os próprios olhos”.

Pontos principais

O Claude Code pode ser fiel ao pedido e, mesmo assim, ampliar de fininho a área em que mexe. A conferência antes de fechar serve para achar esse “transbordamento”.
A revisão segue uma ordem fixa de 3 minutos: conferir o escopo, conferir o diff, verificar e, por fim, escolher os arquivos para o stage. Quatro passos.
A IA executa “a mudança”. A pessoa decide “até onde entra neste commit”. Não misture os dois papéis.
Deixei um script de conferência pronto pra copiar e colar. Ele mostra o git status e o resumo do diff numa tela só, para você deixar passar menos coisa.
Não relaxe só porque o build passou. O que aparece na página publicada e o conteúdo das traduções precisam de um segundo par de olhos.

Por que colocar a conferência “logo antes de fechar”

O melhor momento para conferir não é antes de começar, nem no meio do trabalho: é logo antes de commitar. O motivo é simples: só nesse instante a foto completa dos arquivos que a IA realmente tocou fica congelada.

Por mais que você diga “mexe só aqui, viu?” antes de começar, a IA vai pôr a mão no que ela julgar que “seria melhor já arrumar de uma vez”. Se você para no meio, ainda não dá pra saber o que olhar, porque o trabalho não fechou. Tudo terminado, um passo antes de fechar: é aí que dá pra comparar “o que pedi” com “o que de fato mudou”.

A parte em que eu mais me acidento é a que envolve receita. Por exemplo, basta um caractere fora de lugar no link para a página de produto e o leitor que clicou cai num “página não encontrada”. Por melhor que seja o texto, se o destino do link está quebrado, a oportunidade de venda morre ali. Por isso, quando olho o diff, a primeira coisa que confiro é se algum destino de link mudou.

Se você ainda não firmou o uso básico do Claude Code, vale primeiro pegar a visão geral no guia de primeiros passos do Claude Code. Com isso, o sentido deste roteiro de conferência fica bem mais claro.

A ordem da conferência que cabe em 3 minutos

Se não dá pra fazer todo dia, não serve. Por isso o roteiro tem só 4 passos. Não é uma auditoria perfeita; é uma trava de segurança leve.

Diga o escopo em voz alta. Qual foi o pedido desta vez? Repita numa frase só. Tipo: “ajustar o texto do botão do artigo”. Essa frase vira a régua que mede tudo depois.
Olhe a lista de arquivos alterados. Com git status, veja quem mudou. Se aparecer algum arquivo fora da frase que você falou, marque mentalmente, como se colasse um post-it.
Leia o diff dos arquivos que você marcou. Veja o conteúdo só dos arquivos fora do escopo. Decida, um por um: se for uma mudança útil, mantenha; se não tem relação, deixe de fora desta vez.
Escolha só os arquivos necessários e coloque no stage. Nada de jogar tudo com git add .. Adicione, pelo nome, só os arquivos que o pedido de hoje precisa.

O ponto-chave é o passo 3. Não transforme o que a IA ampliou num “aceito tudo” ou “rejeito tudo”. Um por um, a pessoa decide se mantém ou tira. É chato, mas pular isso é o que gera o acidente dos 18 arquivos lá do começo.

O que delegar à IA e o que a pessoa decide

Se essa linha fica turva, a conferência vira só teatro. Eu divido assim:

O que fazer	Quem	Por quê
Executar as correções de texto ou código	IA	É muito volume e dá pra fazer de forma mecânica
Corrigir erro de sintaxe e deslizes óbvios	IA	A regra é clara e fácil de automatizar
Decidir se a mudança entra neste commit	Pessoa	Só a pessoa conhece a intenção do pedido
Conferir destino de link e a página publicada	Pessoa	Build passar não garante o conteúdo
Deletar, mexer em dado de produção ou cobrança	Pessoa	Acidente sem volta exige aprovação humana

Se você delegar até o “decida se inclui” pra IA, ela vai querer incluir, como se fosse óbvio, tudo o que ela mesma mexeu. Mantenha a decisão na sua mão. Esse é o maior segredo para reduzir acidentes.

Modelo de prompt pra copiar e colar

Quando for pedir ajuda da IA na conferência, o truque é não deixar ela “se autoavaliar”, e sim “listar os fatos”. Você pode colar o modelo abaixo do jeito que está.

Vou commitar agora. Antes de fechar, relate só os fatos a seguir. A decisão é minha.

1. Resuma o pedido desta vez em uma frase
2. Liste os arquivos alterados no git status (inclusive os não rastreados)
3. Dentre eles, quais parecem fugir da frase do pedido, e por quê
4. Se houver mudança que afete links ou a página publicada, indique o trecho exato

Não escreva "está tudo certo". Apenas alinhe os elementos para eu decidir.

A última frase é o que faz a diferença. Sem ela, a IA fecha tudo com um gostoso “nenhum problema, pode commitar”, e o sentido da conferência some. Os detalhes de como montar prompts assim estão em engenharia de prompt avançada.

Script de conferência que roda na hora

Ficar digitando git status e git diff separados toda vez é chato, então deixo aqui um script que joga o panorama das mudanças numa tela só. Preparei versão PowerShell e versão bash. O conteúdo é só isto: alinhar “a lista de arquivos alterados” e “as linhas adicionadas/removidas por arquivo”.

Versão PowerShell (Windows).

# precommit-check.ps1
# Antes do commit, confere arquivos alterados e volume de mudanca numa tela so

Write-Host "=== Arquivos que toquei desta vez ===" -ForegroundColor Cyan
git status --short

Write-Host "`n=== Volume de mudanca por arquivo (adicao / remocao) ===" -ForegroundColor Cyan
git diff --stat HEAD

Write-Host "`n=== Checklist de conferencia ===" -ForegroundColor Yellow
@(
  "Consigo dizer o pedido em uma frase",
  "Nao entrou nenhum arquivo fora do escopo",
  "Vi o destino dos links e a pagina publicada",
  "Vou stagear so os arquivos necessarios desta vez"
) | ForEach-Object { Write-Host "  [ ] $_" }

Versão bash (macOS / Linux / Git Bash).

#!/usr/bin/env bash
# precommit-check.sh
# Antes do commit, confere arquivos alterados e volume de mudanca numa tela so

echo "=== Arquivos que toquei desta vez ==="
git status --short

echo ""
echo "=== Volume de mudanca por arquivo (adicao / remocao) ==="
git diff --stat HEAD

echo ""
echo "=== Checklist de conferencia ==="
for item in \
  "Consigo dizer o pedido em uma frase" \
  "Nao entrou nenhum arquivo fora do escopo" \
  "Vi o destino dos links e a pagina publicada" \
  "Vou stagear so os arquivos necessarios desta vez"; do
  echo "  [ ] $item"
done

Para rodar, é só isto.

bash precommit-check.sh

Esse script não decide nada sozinho. Para não quebrar a premissa de que a decisão é da pessoa, ele de propósito só “alinha e mostra”. Quando os 4 itens da checklist estiverem todos preenchidos, adicione só os arquivos necessários com git add nome-do-arquivo e commite.

Três cenas em que isso pega na prática

1. Antes de publicar artigo ou material. Ao publicar vários artigos multilíngues de uma vez, às vezes um arquivo de tradução fica em inglês. O build passa, mas o conteúdo não foi traduzido. Não se contente em ver só o nome do arquivo no diff: confira na página publicada até o idioma do corpo do texto.

2. Reescrita de arquivo existente. Você acha que mexeu só no texto, mas os links da página e até o nome do produto foram reescritos junto. Se você definir o escopo numa frase, como “melhorar o texto”, a mudança de link fica fora do escopo e você consegue parar e olhar.

3. Adoção pela equipe. Registre até onde o Claude Code avançou sozinho e em que ponto perguntou a uma pessoa. Se você opera com regras de aprovação vagas (o que pode seguir automático, o que precisa perguntar), cada membro acaba se acidentando de um jeito diferente e vira bagunça.

Armadilhas comuns e como corrigir

Armadilha 1: jogar tudo com git add .. Você arrasta junto mudanças não salvas de outro trabalho. A correção é simples: largar o . e adotar o hábito de stagear pelo nome do arquivo. Mesmo parecendo trabalhoso, esse é o seguro mais rápido.

Armadilha 2: relaxar porque o build passou. O build só olha a sintaxe; ele não vê se o destino do link está certo nem se a tradução foi traduzida de verdade. A correção é abrir a página publicada de fato e conferir, com os olhos, título, corpo e destino dos links. A aprovação da máquina e a aprovação humana são coisas diferentes.

Armadilha 3: perguntar “está tudo certo?” pra IA e encerrar. A IA, se você pedir, tende a dizer “está, sim”. A correção é instruir, como no modelo de prompt acima, “não escreva julgamento, só alinhe os fatos”. Quando o sujeito da decisão volta a ser a pessoa, a conferência começa a funcionar.

Mais maneiras de transformar a conferência em hábito estão em dicas de produtividade no Claude Code. O comportamento oficial de opções do git como --stat você confere na documentação oficial do Git.

Perguntas frequentes

P. Não tenho 3 minutos toda vez pra conferir. R. Nos dias de mudança pequena, acaba em 1 minuto. Os 3 minutos aparecem nos dias com muitos arquivos fora do escopo, e esses são justamente os dias em que a conferência é necessária. Pense no tempo gasto como um termômetro do perigo.

P. Não posso deixar a IA fazer até o stage? R. Se for um trabalho pequeno que você sabe que é seguro, tudo bem deixar. Mas recomendo manter na mão da pessoa a decisão final de “quais arquivos incluir”. É aí que mora a porta de entrada dos acidentes.

P. O que escrever na mensagem de commit? R. Duas coisas: “o que mudou” e “com o que verifiquei”. Por exemplo: “ajusta texto do botão, conferi o destino do link na página publicada”. Quando você reler depois, fica na cara se houve verificação ou não.

P. E se o arquivo fora do escopo for, na verdade, uma mudança boa de fazer? R. Mesmo assim, deixe de fora desta vez. Você só separa em outro commit; não está apagando. Manter “um commit, uma intenção” facilita rastrear depois.

O que eu de fato testei

Depois do tal episódio dos 18 arquivos, passei a encaixar esses 4 passos antes de cada commit. Testei em três cenários: publicar artigo, reescrever arquivo e mudar configuração.

O que mais funcionou foi o primeiro passo, “repetir o pedido numa frase”. Só de falar isso em voz alta, os arquivos fora do escopo passaram a saltar pra minha vista. Quando parei de digitar git add . depois de rodar o script de conferência e passei a stagear os arquivos pelo nome, os acidentes de arrastar outro trabalho junto foram a zero.

E o que me surpreendeu foi o efeito de mudar a pergunta pra IA, de “está tudo certo?” para “só alinhe os fatos”. A mesma IA virou, de repente, uma parceira útil de conferência. Em vez de procurar uma IA mais esperta, devolver o sujeito da decisão pra pessoa. Esse foi, pra mim, o lance mais discreto e o mais eficaz.

Quando você quiser levar o design de permissões e as checagens antes da publicação para a operação de toda a equipe, na consultoria e treinamento a gente monta junto o desenho concreto.