BrazLabsLaboratório de Soluções DigitaisCursos e infoprodutos
Claude Code na Prática Todas as aulas
Módulo 3 · Fluxos do dia a dia

Aula 06O fluxo Explorar → Planejar → Fazer → Guardar

versão do app Claude Desktop15 min de estudo
Prefere o terminal? Veja esta aula na versão do terminal
Inscreva-se no canalOs vídeos da versão do app vão para o canal da BrazLabs no YouTube.

🖥️ Versão Desktop. Nesta aula, quase tudo acontece na aba Code do app Claude Desktop: no seletor de modo, na caixa de mensagem e no painel Browser. Um comando pode aparecer só na instalação do Git: no Linux, ela usa o terminal do sistema, e no Mac, se a janela de instalação não abrir sozinha, também. A aula mostra exatamente o que digitar.

Objetivos

Ao final desta aula você vai saber:

  • Usar as quatro etapas do fluxo numa mudança grande: explorar, planejar, fazer e guardar
  • Saber quando dá para pular o plano e pedir direto
  • Preparar o Git na pasta da sua página e guardar uma versão dela
  • Deixar o arquivo de senhas de fora das versões
  • Dar ao Claude um critério de pronto que se vê na tela, e conferir no painel Browser

Se você levar uma única coisa deste curso, que seja este fluxo: Explorar, Planejar, Fazer e Guardar.

Sem ele, a maioria das pessoas pula direto para o "faz aí", e acaba corrigindo a rota muitas vezes depois.

 🔍 Explorar  →  🗺️ Planejar  →  🛠️ Fazer  →  💾 Guardar
 (entender a     (o plano e o     (mudança por    (uma versão
  página)         critério)        mudança)        para voltar)

💡 Quando pular o plano: se você consegue descrever a mudança em uma frase (trocar um texto, mudar uma cor, corrigir um erro de digitação), peça direto. O plano vale a pena quando a mudança mexe em várias partes da página, quando você não tem certeza de como fazer ou quando não conhece bem aquela parte.

Nesta aula, você passa pelas quatro etapas numa mudança de verdade: o cardápio com filtro. Os três doces da sua página viram seis, e quatro botões (Todos, Bolos, Docinhos e Tortas) mostram só os doces de cada tipo. Antes, você prepara a última etapa, guardar, que precisa de um programa novo: o Git.

Antes de começar: o Git, para guardar versões

O Git é um programa que guarda as versões dos seus arquivos. Cada vez que você pede, ele tira uma foto da pasta inteira, com uma frase dizendo o que mudou, e você pode voltar a essa foto quando quiser. É como o histórico de versões de um documento na nuvem, só que é você quem decide quando tirar a foto.

Guardar uma versão (o Git chama de commit) fica no seu computador. Nada vai para a internet: publicar é outra coisa, que a Aula 19 mostra.

Você prepara o Git uma vez, em quatro passos. Depois, guardar uma versão vira um pedido de uma linha.

1. Confira se o Git está instalado

Numa sessão da aba Code, na pasta da sua página, pergunte ao Claude:

O Git está instalado neste computador?

Ele confere e responde. Se não estiver, instale:

  • Windows: instale o Git for Windows, o mesmo da Aula 03. Na Aula 03, ele era recomendado; a partir desta aula, você precisa dele. Baixe pelo link e vá avançando com as opções que já vêm marcadas. Depois, feche o app e abra de novo, para ele encontrar o Git.
  • Mac: o próprio Mac pode abrir uma janela oferecendo instalar as ferramentas de linha de comando (as command line developer tools, que trazem o Git). Clique em Instalar e espere terminar. Se a janela não abrir, abra o Terminal do Mac, como na Aula 00, digite xcode-select --install e aperte Enter: a mesma janela aparece.
  • Linux: no terminal do sistema, digite sudo apt install git e aperte Enter. O sudo pede a senha do seu usuário, e é normal nada aparecer na tela enquanto você digita.

Depois, pergunte de novo ao Claude se o Git está instalado.

2. Diga ao Git quem assina as versões

O Git assina cada versão com um nome e um e-mail. Isso se faz uma vez só por computador, e vale para todos os seus projetos. Peça ao Claude, com os seus dados:

Configure o Git com o meu nome, Fulana de Tal, e o e-mail fulana@exemplo.com, para assinar as versões.

⚠️ O nome e o e-mail ficam gravados em cada versão, para sempre. Se um dia você publicar o projeto na internet, como na Aula 19, qualquer pessoa vai poder ver. Por isso, use o seu nome e um e-mail que você não se importe de mostrar.

3. Transforme a pasta num repositório

Um repositório é a pasta que o Git acompanha. Para isso, o Git cria dentro dela uma pasta escondida, a .git, onde guarda todas as versões. Não mexa nela e nunca apague: é ali que fica o histórico. Como o nome começa com ponto, ela fica escondida, como o .env (Aula 00).

As versões seguem uma linha principal. Peça que ela se chame main: é o nome que o curso usa daqui em diante, e o mesmo que o GitHub usa como padrão.

4. Deixe as senhas de fora, antes da primeira versão

Lembra do .env, o arquivo da senha falsa da Aula 05? Ele não pode entrar nas versões. Para isso existe o .gitignore: um arquivo com a lista do que o Git não guarda.

Ele precisa existir antes da primeira versão. O que já entrou numa versão continua lá, mesmo que você ponha o nome no .gitignore depois.

💡 Duas travas, duas portas. A regra deny da Aula 05 impede o Claude de ler o .env. O .gitignore impede o .env de entrar nas versões e, um dia, de ir para a internet junto com elas. Uma não substitui a outra.

Agora, um pedido só faz os passos 3 e 4 e guarda a primeira versão, a página como está hoje:

texto
Transforme esta pasta num repositório do Git, com a linha principal
chamada main. Antes de guardar qualquer coisa, crie um .gitignore que
deixe o .env de fora. Depois, guarde a primeira versão, com a mensagem
"Página antes do cardápio". Explique cada comando antes de rodar.

No Manual, cada comando espera a sua aprovação, menos os que só olham. Não entendeu algum? Recuse e escreva na caixa de mensagem: "antes, explique em português simples o que esse comando faz", como na Aula 05. Quando ele terminar, confira: "confira se o .env ficou de fora da versão guardada".

💡 Com versões guardadas, você não precisa mais fazer cópias de arquivo para se proteger, como o index-copia.html da Aula 05. Se quiser, apague a cópia; se preferir, deixe.

1. Explorar: entender antes de mexer

O jeito mais rápido de fazer as duas primeiras etapas é no Plan Mode (Aula 04): nele, o Claude lê os arquivos e pensa no caminho, sem mudar nada. No seletor de modo, na linha abaixo da caixa de mensagem, escolha Plan e peça:

Leia os arquivos da página e me explique, em português simples, como ela está organizada. Não mude nada.

Ele conta, por exemplo, que o cardápio fica no index.html, que as cores ficam no estilo.css e que o botão do modo escuro troca as cores da página inteira. Explorar serve aos dois: o Claude junta o que precisa saber, e você descobre onde a mudança vai mexer.

2. Planejar: o plano e o critério

Ainda no Plan, faça o pedido com as cinco partes da Aula 04:

texto
Quero um cardápio com filtro na página da confeitaria. Troque os três
doces por seis: dois bolos, dois docinhos e duas tortas, cada um com
nome e preço. Em cima do cardápio, coloque quatro botões: Todos, Bolos,
Docinhos e Tortas. Ao clicar num botão, só os doces daquele tipo
aparecem; em Todos, os seis voltam. O modo escuro tem de continuar
funcionando, com os botões fáceis de ler nos dois modos. Quando
terminar, abra a página no painel Browser e confira cada botão.
Parte No exemplo
O quê um cardápio com filtro, com seis doces
Onde quatro botões em cima do cardápio
Comportamento ao clicar, só os doces daquele tipo aparecem; em Todos, os seis voltam
Critério o modo escuro continua funcionando, com os botões fáceis de ler
Verificação conferir cada botão no painel Browser

O critério de pronto é o que se vê na tela. "Funcionar direito" não serve, porque não dá para conferir. "Ao clicar em Bolos, só os bolos aparecem" serve: você clica e vê. E repare na parte do modo escuro: uma mudança nova pode estragar algo que já funcionava, então o critério também confere o que já existia.

O Claude devolve um plano de ação. Revise. Ele atende ao que você pediu? Se não, escreva o ajuste na caixa de mensagem, por exemplo: "Deixe destacado o botão escolhido, para eu saber qual filtro está ligado." Ele revisa o plano antes de qualquer mudança.

🎯 Este é o melhor momento para corrigir o rumo, porque nada na página mudou ainda.

3. Fazer: mudança por mudança

Quando o plano estiver bom, troque o seletor para Manual e escreva: "Plano aprovado, pode seguir." A cada mudança, o app mostra o diff, o antes e o depois do arquivo, e você aceita ou recusa. Aceite as que fizerem sentido.

Quando ele terminar, confira com os próprios olhos. Clique no caminho do index.html na conversa: a página abre no painel Browser, ao lado da conversa. (O painel também abre com um clique em Browser, na barra de título da sessão, ou com Cmd + Shift + B no Mac, Ctrl + Shift + B no Windows.) Clique em cada um dos quatro botões; depois, ligue o modo escuro e clique de novo.

Você também pode pedir que o Claude confira ali: no painel, ele tira prints, clica nos botões e corrige o que encontrar.

Abra a página no painel Browser, clique em cada botão do filtro, ligue o modo escuro e me mostre um print. Confira se o critério foi cumprido.

Prefere o seu navegador de sempre? Também vale: abra a página, tire um print e arraste para a caixa de mensagem, como na Aula 04.

O Claude vai fazer o possível para deixar tudo certo antes de dizer que terminou, mas às vezes você precisa entrar em cena: viu algo errado, peça o ajuste. Com o plano, você também tem o histórico de como chegou ao resultado, o que ajuda nos próximos pedidos.

4. Guardar: uma versão para voltar

Antes de guardar, clique no indicador de linhas alteradas, como +38 -6, para ver o que mudou, arquivo por arquivo. Mudou algum arquivo que você não pediu? Pergunte por quê. A Aula 09 mostra como revisar com calma.

Ficou bom? Guarde uma versão:

Guarde uma versão com uma mensagem em português explicando o que mudou.

O Claude escreve a mensagem, como "Cardápio com filtro por tipo de doce", e roda os comandos do Git. No Manual, eles esperam a sua aprovação, como antes. Para ver o resultado, peça: "me mostre as versões guardadas". A sua pasta agora tem duas: a página antes do cardápio e o cardápio com filtro.

Guarde uma versão sempre que algo funcionar e antes de começar uma mudança grande. A versão de hoje é o ponto de volta da próxima mudança: se der errado, você volta. A Aula 10 mostra como.

Quando ganhar confiança, o Accept edits é o meio-termo da Aula 05: as mudanças nos arquivos passam direto, e você revisa tudo depois, no diff, antes de guardar.

E repita o ciclo na próxima tarefa.

Para ir além (opcional): o mesmo fluxo num projeto de programação

🔧 Para ir além (para quem já programa; pode pular): esta parte mostra o fluxo como ele costuma ser usado num projeto de código, com testes, subagentes e mensagens de commit no padrão do time. Se você nunca programou, pule direto para o Na prática.

Explorar e planejar. No Plan (o atalho Cmd + Shift + M no Mac, ou Ctrl + Shift + M no Windows, abre o menu de modos), o Claude lê os arquivos e roda comandos para explorar o projeto, até entender como vai atacar a implementação. Um pedido típico:

texto
Preciso adicionar conversão para WebP no nosso pipeline de upload de
imagens. Descubra em que ponto do pipeline isso deve acontecer, se
precisamos de novas dependências e como abordar a implementação.

Ele lê os arquivos relevantes, faz algumas buscas na web e entrega o plano. Se você só quer um resumo geral da base de código, sem intenção de mudar nada, peça ao subagente de exploração (Aula 12), mesmo fora do Plan Mode. Depois de aprovar, o modo que você escolhe define como ele segue: Accept edits, Manual ou, se aparecer no seletor, Auto, com a checagem de segurança em segundo plano.

Um critério de sucesso com testes. Num projeto de código, o critério costuma incluir os testes:

texto
Critério de sucesso: todo upload de JPG ou PNG deve ser salvo como .webp,
com qualidade 80, e os testes de upload existentes devem continuar
passando.

Dê ao Claude uma suíte de testes que ele possa rodar continuamente para se validar. Ele pode até escrever os testes, mas, antes de confiar neles, garanta que são uma fonte confiável da verdade, para evitar falsos positivos.

O painel Browser num app web. O Claude sobe o servidor de desenvolvimento, abre o seu app no painel e confere as próprias mudanças: tira prints, inspeciona o DOM, clica nos elementos e preenche formulários. Por padrão, ele faz essa conferência depois de cada edição (mais na Aula 22). O painel usa um perfil de navegador limpo, sem os seus logins. Para o Claude agir nos sites em que você está logado, o caminho é a extensão Claude in Chrome, que a versão terminal desta aula liga com claude --chrome.

Comentários no diff. No diff, clique numa linha, escreva o comentário e aperte Enter. Com vários comentários prontos, envie todos de uma vez com Cmd + Enter no Mac (Ctrl + Enter no Windows). O Claude lê os comentários e faz as mudanças.

Revisão com olhos frescos. Antes de commitar, peça um subagente revisor de código. Um subagente começa com o contexto limpo, sem o viés que a sessão acumulou. Peça um subagente novo, e não um fork: o fork herda a conversa inteira, com o viés junto. Na Aula 09, o /code-review faz essa revisão por você; nas sessões locais do app, o resultado chega num card Code review.

Mensagem no padrão do time. Peça a mensagem de commit no padrão que o projeto usa:

texto
Gere uma mensagem de commit para essas mudanças seguindo o padrão
Conventional Commits, em português, e faça o commit.

Na prática

Use a pasta da página que você criou na Aula 03 (a confeitaria, ou a da sua ideia).

  1. Na aba Code, na linha abaixo da caixa de mensagem, escolha Local e a pasta da sua página. Antes da primeira mensagem, escolha Manual no seletor de modo, na mesma linha.
  2. Pergunte: "O Git está instalado neste computador?" Se não estiver, instale como mostrado acima e pergunte de novo.
  3. Peça: "Configure o Git com o meu nome, Fulana de Tal, e o e-mail fulana@exemplo.com, para assinar as versões", com o seu nome e um e-mail que você não se importe de mostrar. Não sabe se o seu Git já tem isso? Pergunte antes: "o Git já tem um nome e um e-mail configurados?"
  4. Faça o pedido do repositório, do .gitignore e da primeira versão, como no exemplo acima. Aprove cada comando; se não entender algum, recuse e peça a explicação na caixa de mensagem.
  5. Peça: "confira se o .env ficou de fora da versão guardada".
  6. Troque o seletor para Plan e peça: "Leia os arquivos da página e me explique, em português simples, como ela está organizada. Não mude nada."
  7. Ainda no Plan, faça o pedido do cardápio com filtro, com as cinco partes. Leia o plano e peça um ajuste na caixa de mensagem, como destacar o botão escolhido.
  8. Quando o plano estiver bom, troque o seletor para Manual e escreva: "Plano aprovado, pode seguir." A cada mudança, olhe o diff e aceite as que fizerem sentido.
  9. Clique no caminho do index.html na conversa para abrir a página no painel Browser. Clique nos quatro botões, ligue o modo escuro e clique de novo. Depois, peça: "Abra a página no painel Browser, clique em cada botão do filtro, ligue o modo escuro e me mostre um print. Confira se o critério foi cumprido."
  10. Clique no indicador de linhas alteradas para ver o que mudou. Depois, peça: "Guarde uma versão com uma mensagem em português explicando o que mudou" e, no fim, "me mostre as versões guardadas".

Resumo

  • Explorar é entender antes de mexer: no Plan, o Claude lê a página e explica como ela está organizada, sem mudar nada.
  • Planejar é o pedido com as cinco partes e um critério que se vê na tela. É o melhor momento para corrigir o rumo, na caixa de mensagem.
  • Fazer é aprovar mudança por mudança, no Manual, e conferir com os próprios olhos: no painel Browser, que abre com um clique no caminho do index.html, ou no seu navegador, com um print.
  • Guardar é pedir ao Git uma versão, com uma frase do que mudou: um ponto para onde dá para voltar. Guardar não envia nada para a internet.
  • O .gitignore deixa o .env de fora das versões, e precisa existir antes da primeira.
  • O nome e o e-mail que assinam as versões ficam gravados nelas: use um e-mail que você não se importe de mostrar.
  • Mudança que cabe numa frase dispensa o plano: peça direto.

Na próxima aula, você conhece a memória de trabalho do Claude, o contexto, e aprende a cuidar dela numa conversa longa.

Perguntas de fixação

Três perguntas rápidas para conferir se a ideia principal da aula ficou. Escolha uma opção: a página mostra se você acertou e explica a resposta.

Pergunta 1 de 3

Em qual destas mudanças na página vale mais a pena planejar antes de fazer?

Ver a resposta

Resposta: d) O plano vale a pena quando a mudança mexe em várias partes da página, quando você não tem certeza de como fazer ou quando não conhece bem aquela parte. Se dá para descrever a mudança em uma frase, como trocar um texto ou uma cor, peça direto (Aula 06).

Pergunta 2 de 3

Você vai guardar a primeira versão da pasta, e nela está o .env, com a senha. O que fazer antes?

Ver a resposta

Resposta: c) O .gitignore é a lista do que o Git não guarda, e ele vem antes da primeira versão: o que já entrou numa versão continua lá, mesmo que o nome vá para o .gitignore depois. A regra deny impede o Claude de ler o .env, mas não impede o Git de guardar. E guardar fica no computador, mas as versões vão junto se um dia você publicar o projeto (Aula 06).

Pergunta 3 de 3

Qual destes é um bom critério de pronto para o cardápio com filtro?

Ver a resposta

Resposta: a) O critério de pronto é o que se vê na tela: dá para conferir clicando e olhando, sem ler código. Abrir sem erro não prova que o filtro funciona, e o Claude dizer que terminou não é conferir (Aula 06).