Rotina de 15 minutos no Claude Code para iniciantes: o ritual seguro da manhã

Numa sexta à noite, joguei pro Claude Code um “arruma tudo o que tiver de errado nesse projeto” e fui dormir.

Na manhã seguinte, 23 arquivos alterados. Tinha código funcionando, inclusive. Só que eu não conseguia explicar pra mim mesmo o que de fato tinha melhorado, nem o que eu deveria conferir. Levei uma hora só lendo o diff de cima a baixo e, no fim, fiquei com tanto medo que não consegui dar commit em uma única linha.

Pedi muita coisa pra uma IA inteligente e, em vez de avançar, andei pra trás. Essa é a primeira armadilha em que quase todo iniciante cai.

A causa não foi o desempenho do Claude Code. Foi só que eu não tinha decidido como “fechar” o trabalho. Hoje vou te entregar, do jeito que está, a rotina de 15 minutos que faço toda manhã enquanto o café passa.

Pontos principais

• “Arruma tudo” é receita pra acidente. O que você faz todo dia é uma única tarefa pequena, decidida em uma frase.
• Antes de começar a editar, defina primeiro o comando de verificação que diz se o trabalho terminou.
• Depois de trabalhar, basta guardar três coisas: “arquivos que mudaram”, “resultado do comando de verificação” e “o próximo passo”.
• Delegue à IA a parte de pôr a mão na massa. Definir o escopo e apertar o botão de publicar é coisa de gente.
• Copiando e colando o script abaixo, você enfileira automaticamente a checagem de toda manhã.

Por que “fechar pequeno” funciona tão bem para iniciantes

Quando comecei a mexer no Claude Code, minha meta era sempre vaga. “Deixa bom”, “deixa legível”. Assim, nem depois que terminava eu sabia o que a IA tinha feito, nem até onde.

Vale o mesmo para um colega novato. Quem recebe “esse documento aqui, dá um jeito” geralmente fica perdido. Já quem recebe “troca os números da página 3 pela versão mais recente e confere se a tabela não quebrou” sabe agir na hora e ainda consegue julgar sozinho se terminou.

O importante na rotina diária não é escrever uma instrução genial de primeira. É dividir em pedaços pequenos e dar a eles uma forma cujo fim você consiga julgar. Quando se aprende isso, até um iniciante consegue dizer todo dia: “hoje cheguei até aqui”.

Aliás, a base desse raciocínio se conecta com outros dois textos: Como começar com o Claude Code e O básico do gerenciamento de permissões. Vale primeiro arrumar o ambiente por lá e só depois encaixar este hábito por cima.

Em 15 minutos, são só 4 passos

O que faço toda manhã são apenas estes quatro. E a ordem é sempre a mesma. Fixar a ordem faz o corpo agir sem precisar pensar.

1. Escreva a menor tarefa de hoje em uma frase. Algo como “reescrever só as 3 linhas de introdução do README”, num tamanho em que dá pra enxergar o fim. Tarefa grande fica de fora de propósito hoje.
2. Defina o comando de verificação antes. Decida o formato da meta antes de começar a editar: “se npm run build passar, está OK” ou “se um teste ficar verde, está OK”.
3. Trabalhe e confira na ordem diff, build e URL pública. Não publique de cara; vá olhando primeiro o que a máquina consegue julgar.
4. Deixe só uma linha para a próxima vez. Anote “o risco que sobrou” e “a próxima tarefa mínima”. Isso vira o ponto de partida da manhã seguinte.

O ponto-chave é o passo 2. Se você começa a editar sem decidir antes o comando de verificação, volta direto pra aquela sexta à noite do “acho que arrumou, mas não tenho certeza”. Estique a fita de chegada antes de correr. Só isso já deixa o trabalho diário muito mais leve.

O que delegar à IA e o que você decide

Acho que é aqui que o iniciante mais se confunde. Não dá pra largar tudo na mão da IA, mas se você for fazer tudo sozinho, perde o sentido de usá-la. Coloquei a linha divisória numa tabela.

Situação	Delegar à IA	Você decide / aperta
Definir escopo	Levantar candidatos	Fechar a frase do que fazer hoje
Editar	Escrever código ou texto	A direção do que corrigir
Verificar	Rodar build e testes	Qual verificação será a meta
Publicar	Gerar o resumo do diff	Apertar o botão de publicar
Operação perigosa	Perguntar “posso fazer?”	Decisão final de apagar / subir em produção

O critério na dúvida é simples. O que dá pra refazer vai pra IA; o que não tem volta fica com você. Editar arquivos pode ser refeito à vontade, então delega. Publicar em produção ou apagar arquivos, no começo, aperte sempre com a própria mão. Só depois, conforme se acostuma, promova aos poucos algumas operações para o automático. As configurações finas de permissão estão todas reunidas na documentação oficial do Claude Code, então, se ficar em dúvida na linha divisória, vale dar uma olhada por lá.

Modelo de pedido para copiar e colar

Escrever o pedido do zero toda vez deixa o tamanho da tarefa instável. Eu deixo este modelo colado no app de notas e preencho as lacunas toda manhã.

Menor tarefa de hoje: (uma frase aqui. Ex.: reescrever as 3 linhas de introdução do README)
Escopo que pode tocar: (ex.: só o README.md. É proibido alterar outros arquivos)
Como verificar a conclusão: (ex.: o npm run build precisa passar)

Como proceder:
1. Primeiro, sem alterar nada, leia o estado atual e resuma.
2. Edite apenas o escopo acima. Não toque no que está fora dele.
3. Depois de editar, relate os nomes dos arquivos alterados e o resultado da verificação.
4. Se precisar apagar, subir em produção ou enviar para fora, não execute: pergunte antes.

Só de incluir as duas linhas “não toque fora do escopo” e “operação perigosa, pergunte antes”, o acidente dos 23 arquivos do começo praticamente desaparece. Em vez de dar liberdade à IA, a ideia é entregar uma caixa segura.

Script de verificação que roda copiando e colando

Se eu fizer a checagem da manhã digitando na mão, esqueço. Eu deixo este script como morning-check.mjs e rodo antes de passar o café. Funciona se você tiver o Node.js instalado.

// morning-check.mjs : enfileira e executa a checagem de toda manhã em ordem
import { execSync } from "node:child_process";

// Enfileire de cima pra baixo os comandos que quer verificar. Ajuste ao seu projeto.
const checks = [
  { label: "Arquivos alterados", cmd: "git status --short" },
  { label: "Se o build passa", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // Mostra o resultado direto na tela. Se der erro, vai pro catch abaixo.
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(sem saída)");
  } catch (e) {
    allOk = false;
    console.log("Falhou:", e.message.split("\n")[0]);
  }
}

console.log("\n--- Fechamento de hoje ---");
console.log(allOk ? "Verificação OK. Deixe a próxima tarefa mínima em uma linha." : "A verificação travou. Conserte antes de seguir.");

Executar é só isto.

node morning-check.mjs

O segredo é reescrever o conteúdo de checks de acordo com o seu projeto. Se tiver testes, adicione npm test; se for um site estático, acrescente a verificação da URL pública. Só de os mesmos comandos rodarem na mesma ordem toda manhã, as checagens esquecidas quase somem. Eu acrescentei aqui também uma verificação de “será que parei sem dar o commit final?”.

Cenários em que isso funciona (três deles)

Exemplo 1: no primeiro dia, só faça o mapa do repositório Você não precisa corrigir código de cara. Peça à IA para resumir “quais diretórios são perigosos” e “onde estão os arquivos de configuração”, e só de ler isso o primeiro dia já é um sucesso. O trabalho dos dias seguintes fica bem mais rápido.

Exemplo 2: no segundo dia, só um parágrafo do README Crie uma pequena experiência de vitória. Reescreva 3 linhas de introdução e confira com npm run build se nada quebrou. Só isso. Quando você fecha algo pequeno e leva até a verificação, ganha a sensação de “eu também consigo tocar isso”.

Exemplo 3: no terceiro dia, uma melhoria pequena ligada a número Corrigir um título de artigo, adicionar um teste, consertar um link quebrado. Escolha uma melhoria pequena cujo resultado dê pra ver. O importante é empilhar todo dia uma “mudança que passou até a verificação”.

Exemplos de falha e como corrigir

Sendo honesto, eu tropecei várias vezes nestas três.

Armadilha 1: tentar fazer tudo de uma vez. “Tudo o que estiver errado” gera um diff gigante e impossível de verificar. A correção é simples: limite a frase de hoje a “uma só”. O resto vai para a nota de amanhã.

Armadilha 2: dar por concluído só com o build local. Mesmo que npm run build passe, não é garantido que a URL pública esteja saindo certo. Uma vez o build estava verde, mas a página pública continuava antiga e eu não percebi. A correção é, depois de publicar, abrir a URL de verdade e ver com os próprios olhos se o título e o começo do texto já refletem a mudança desta vez.

Armadilha 3: aprovar operações perigosas no embalo. Quando aparece um diálogo de confirmação, o iniciante tende a apertar “Yes” no automático. Se vier a confirmação de apagar ou subir em produção, pare a mão por um instante. Se estiver em dúvida sobre a decisão, o certo é não fazer essa operação hoje. A forma de pensar as permissões também aparece bem em explicação para não engenheiros.

O formato da nota que fica para a próxima vez

A nota final pode ser curta. Mas, para o seu eu da manhã seguinte não refazer a mesma decisão, vale fixar pelo menos o formato.

- O que fiz hoje: reescrevi as 3 linhas de introdução do README
- Como verifiquei: npm run build passou / conferi o título pela URL pública
- Risco que sobrou: há 2 links de imagem quebrados
- Menor tarefa de amanhã: consertar só 1 dos links de imagem

Com essa nota, o tempo gasto de manhã com “por onde começo?” vai a zero. Desde que comecei isso, sinto que a largada da manhã ficou uns 5 minutos mais rápida.

Perguntas frequentes

P. Não consigo separar nem 15 minutos por dia. Dá pra encurtar mais? Dá. No começo, só “escrever a menor tarefa de hoje em uma frase” já vale. Se você ao menos criar o hábito de decidir o comando de verificação, o tempo de trabalho diminui sozinho.

P. Não sei qual é o meu comando de verificação. Se o projeto tem npm run build ou npm test, já basta começar por aí. Se não tem nada, “abrir a URL pública e olhar com os olhos” é uma verificação válida. No início, está tudo bem decidir só uma coisa que a máquina consiga julgar.

P. Não seria mais rápido deixar tudo na mão da IA? No curto prazo, parece que sim. Mas uma “mudança que você não consegue explicar o que melhorou” acaba virando uma releitura completa depois. Fechar pequeno é, no total, mais rápido — essa é a minha experiência real.

P. Qual é a primeira coisa que um iniciante deve fazer? Fazer o mapa do repositório. Antes de corrigir código, peça à IA para resumir onde está cada coisa e leia. Essa é a base para avançar com segurança.

P. Essa rotina serve também para adotar em equipe? Serve. Só que, em equipe, vale documentar antes “quem aprova a publicação” e “qual verificação será a meta”: assim o hábito individual vira direto a regra da equipe.

O que aconteceu quando testei de verdade

Desde aquela sexta à noite, parei de me atormentar com “até onde delegar à IA”. No lugar disso, o que decido toda manhã são só duas coisas: a frase de hoje e o comando de verificação.

Rodei o morning-check.mjs por duas semanas e o que mais mudou foram as checagens esquecidas. Antes eu dava commit achando que tinha passado o build e, depois, descobria que estava quebrado algumas vezes. Desde que passei a rodar a verificação na máquina sempre na mesma ordem, isso foi a zero.

E a nota de 4 linhas que deixo toda noite. Desde que comecei, sumiu aquele “o que era mesmo pra fazer?” da manhã seguinte. Em vez de caçar o uso genial, feche pequeno e deixe a verificação registrada. É discreto, mas acho que é aqui que se decide a velocidade com que um iniciante avança.

Amanhã de manhã, comece definindo só uma frase e rodando um comando de verificação. Quando, com a prática, você for criando o seu próprio padrão, dê uma olhada na lista de materiais para aumentar seu repertório de modelos de pedido e reduzir ainda mais o número de passos do seu dia.