👾 9 Workflows do Claude Code

O primeiro passo do workflow de bug fix: dar ao Claude Code todo o contexto necessario. Inclua a mensagem de erro, o comportamento esperado vs atual, e os arquivos relevantes.

Sem contexto adequado, o Claude vai chutar solucoes genericas. Com contexto rico - stack trace, logs, arquivo onde o bug acontece - ele investiga de forma cirurgica e acerta de primeira.

Cole o erro completo (stack trace, mensagem, codigo de status). Descreva: "esperava X, recebi Y". Mencione arquivos relevantes. Exemplo: "O endpoint /api/users retorna 500. Stack trace: [cole aqui]. O handler esta em src/routes/users.ts".

Pedir explicitamente ao Claude para investigar a causa raiz antes de propor qualquer solucao. Use frases como "investigue primeiro, nao corrija ainda" ou "me explique a causa raiz antes de mudar codigo".

O instinto do Claude e resolver rapido. Mas bugs complexos precisam de diagnostico correto primeiro. Forcar investigacao evita que ele aplique band-aids que mascaram o problema real.

Prompt: "Investigue este bug sem aplicar nenhuma correcao. Leia os arquivos relevantes, trace o fluxo de dados e me diga qual e a causa raiz." O Claude vai ler codigo, seguir imports e mapear o problema.

Avaliar a analise que o Claude apresentou antes de seguir para a correcao. Confirme se a causa raiz identificada faz sentido e se ele entendeu o fluxo corretamente.

O Claude pode errar no diagnostico. Revisar antes de aplicar a correcao evita que voce introduza novas regressoes. E o checkpoint de seguranca entre investigacao e acao.

Pergunte: "Voce tem certeza que a causa e X e nao Y?". Valide se ele leu os arquivos certos. Se o diagnostico nao convence, peca para investigar mais a fundo antes de continuar.

Agora sim, pedir ao Claude para aplicar a correcao baseada no diagnostico validado. Ele vai editar os arquivos necessarios e fazer as mudancas minimas para resolver o problema.

Depois de investigar e validar, a correcao tende a ser cirurgica. Voce evita mudancas desnecessarias e mantem o diff pequeno, facilitando code review e reduzindo risco de regressao.

Prompt: "Agora aplique a correcao. Faca a mudanca minima necessaria." Revise o diff com git diff. Rode os testes. Se algo nao funcionar, volte ao passo de investigacao.

Usar o Claude para gerar o commit da correcao com mensagem descritiva. O /commit analisa o diff e cria uma mensagem que explica o que foi corrigido e por que.

Um bom commit de bug fix documenta o problema e a solucao. Quando alguem faz git blame meses depois, a mensagem de commit explica o contexto completo da correcao.

Use /commit ou peca: "faca o commit desta correcao com mensagem descritiva". O Claude gera algo como "fix: resolve null pointer in user auth by adding null check before token validation".

Tecnicas avancadas para bug fixing com Claude: usar git bisect com Claude, pedir testes de regressao junto com o fix, e patterns para bugs recorrentes.

Operadores experientes nao so corrigem bugs - eles previnem reincidencia. Pedir teste de regressao junto com o fix garante que o mesmo bug nunca mais volta.

Sempre peca: "alem do fix, escreva um teste que falha sem a correcao e passa com ela". Use git bisect + Claude para rastrear quando o bug foi introduzido. Documente patterns de bugs recorrentes no CLAUDE.md.

Iniciar o desenvolvimento de uma feature usando Shift+Tab para ativar plan mode. O Claude analisa o codebase e cria um plano detalhado sem escrever nenhum codigo ainda.

Features construidas sem planejamento resultam em codigo desorganizado e refatoracoes constantes. Plan mode forca uma arquitetura pensada antes da implementacao.

Ative plan mode com Shift+Tab. Descreva a feature: requisitos, comportamento esperado, restricoes. O Claude vai mapear arquivos afetados, interfaces necessarias e ordem de implementacao.

Revisar criticamente o plano gerado pelo Claude antes de implementar. Verificar se ele considerou edge cases, se a arquitetura faz sentido e se nao falta nenhum componente.

O plano e sua ultima chance de fazer correcoes de curso baratas. Mudar um plano custa zero. Mudar codigo implementado custa horas. Revise agora, economize depois.

Pergunte: "E se o usuario fizer X?", "Voce considerou autenticacao/validacao?", "Qual o impacto em performance?". Ajuste o plano ate ficar satisfeito antes de prosseguir.

Executar o plano passo a passo, pedindo ao Claude para implementar um componente por vez. Nao tente implementar tudo de uma vez - va incrementalmente.

Implementacao incremental permite validar cada parte antes de seguir. Se algo der errado, voce sabe exatamente onde o problema esta. O diff fica pequeno e facil de revisar.

Prompt: "Implemente o passo 1 do plano: criar o modelo de dados." Revise. "Agora o passo 2: criar o endpoint." Revise. Cada passo e um checkpoint validado antes do proximo.

Pedir ao Claude para rodar todos os testes existentes e escrever novos testes para a feature implementada. Verificar que nada quebrou e que a feature funciona como esperado.

Feature sem teste e bomba-relogio. O Claude pode escrever testes unitarios, de integracao e edge cases em segundos. Nao ha desculpa para entregar codigo sem cobertura.

Prompt: "Rode os testes existentes e escreva testes para a nova feature cobrindo happy path e edge cases." O Claude roda npm test / pytest, analisa falhas e cria testes complementares.

Pedir ao Claude para revisar todo o codigo da feature, limpar TODOs, melhorar nomes de variaveis, adicionar comentarios onde necessario e garantir que segue os padroes do projeto.

Codigo funcional nao e suficiente. Codigo limpo, documentado e consistente com o resto do projeto e o que diferencia entrega profissional de prototipo. O polish e o acabamento.

Use /review para uma revisao automatica. Peca: "revise todo o codigo novo, verifique naming, documentacao, edge cases nao tratados e conformidade com os padroes do projeto."

Usar /commit para gerar commits atomicos e descritivos para a feature. Se a feature e grande, divida em commits logicos: modelo, endpoint, testes, etc.

Commits atomicos facilitam code review, rollback e entendimento do historico. Um commit gigante com toda a feature e muito mais dificil de revisar e reverter parcialmente.

Para features grandes, faca commits incrementais: "feat: add user model", "feat: add user API endpoint", "test: add user endpoint tests". Use /commit em cada etapa ou peca ao Claude para organizar os commits.

Antes de refatorar, pedir ao Claude para explicar a arquitetura atual do codigo que sera modificado. Entender dependencias, acoplamentos e razoes pelas quais o codigo esta como esta.

Refatorar sem entender o estado atual e receita para desastre. O codigo pode ter complexidades por boas razoes (edge cases, performance, compatibilidade). Entenda antes de mudar.

Prompt: "Analise a arquitetura atual de [modulo]. Explique as dependencias, o fluxo de dados e quaisquer patterns utilizados. Identifique code smells e divida tecnica." O Claude mapeia tudo antes de tocar.

Estabelecer um objetivo claro para a refatoracao: extrair funcao, renomear, simplificar logica, remover duplicacao, ou melhorar testabilidade. Refatoracao sem objetivo vira mudanca gratuita.

Objetivos claros mantém o escopo controlado. "Refatorar tudo" e impossivel de revisar. "Extrair a logica de validacao para um modulo separado" e concreto e verificavel.

Seja especifico: "Refatore para extrair a logica de parsing do arquivo X para um modulo separado, mantendo a mesma interface publica." Isso da ao Claude um escopo fechado e objetivo mensuravel.

Depois que o Claude aplica a refatoracao, revisar o diff linha por linha. Verificar que o comportamento foi preservado e que apenas mudancas estruturais foram feitas.

Refatoracao por definicao nao muda comportamento. Se o diff mostra logica nova ou condicoes alteradas, algo saiu do escopo. O review do diff e seu guardiao de seguranca.

Rode git diff apos a refatoracao. Peca ao Claude: "revise este diff e confirme que nenhum comportamento foi alterado." Qualquer mudanca semantica e red flag e deve ser revertida ou justificada.

Executar toda a suite de testes apos a refatoracao. Se todos os testes passam, voce tem confianca alta de que o comportamento foi preservado. Se algum falha, a refatoracao introduziu regressao.

Testes sao a rede de seguranca da refatoracao. Sem testes passando, voce nao tem como garantir que a refatoracao foi segura. Este passo e inegociavel.

Peca: "rode todos os testes e me diga se algum falhou." Se um teste falha, e regressao: reverta ou corrija. Se nao ha testes, peca ao Claude para escrever testes ANTES de refatorar.

Commitar a refatoracao com mensagem clara indicando que e uma mudanca estrutural, sem alteracao de comportamento. Convencao: "refactor: [descricao da mudanca]".

Commits de refatoracao devem ser separados de commits de feature. Isso permite reverter refatoracoes independentemente e facilita o entendimento do historico do projeto.

Use /commit. O Claude gera algo como "refactor: extract validation logic into separate module". Nunca misture refatoracao com feature no mesmo commit - sao mudancas com propositos diferentes.

Principios guia para refatoracao eficaz: a regra do boy scout (deixe o codigo melhor do que encontrou), refatoracao oportunistica, e quando NAO refatorar.

Nem toda refatoracao vale a pena. Codigo que funciona, tem testes e ninguem toca nao precisa ser refatorado. Saber quando parar e tao importante quanto saber quando comecar.

Refatore quando: vai mudar o codigo de qualquer forma, codigo duplicado causa bugs, ou testabilidade esta comprometida. NAO refatore: codigo legado estavel que ninguem toca, ou antes de prazo apertado.

Pedir ao Claude para analisar a estrutura geral do projeto: diretorios, tecnologias usadas, arquitetura, entry points e dependencias principais. O mapa de alto nivel.

Sem visao geral, voce vai se perder nos detalhes. Comece de cima: entenda o que o projeto faz, como esta organizado e quais tecnologias usa. Depois zoom in nos detalhes que importam.

Prompt: "Analise este projeto. Me de uma visao geral: qual o proposito, quais tecnologias usa, como esta organizado, quais sao os entry points principais e as dependencias-chave." O Claude varre o projeto inteiro.

Depois da visao geral, fazer drill-down em areas especificas: um modulo, um servico, um fluxo de dados. Perguntar sobre partes especificas que voce precisa entender para sua tarefa.

Voce nao precisa entender o projeto inteiro no primeiro dia. Precisa entender o suficiente para fazer sua tarefa. Zoom in no que importa agora, expanda conforme necessario.

Prompt: "Agora me explique em detalhes como funciona o modulo de autenticacao. Quais arquivos estao envolvidos, qual o fluxo de dados e como os tokens sao gerenciados?" Pergunte o que precisa para sua tarefa.

Pedir ao Claude para tracar o fluxo completo de uma operacao: do input do usuario ate a resposta final. Seguir a cadeia de chamadas entre arquivos e modulos.

Entender o fluxo revela como os modulos se conectam. E a diferenca entre saber que um arquivo existe e entender como ele e usado no contexto real da aplicacao.

Prompt: "Trace o fluxo completo de um request POST /api/orders: do middleware ate o banco de dados e de volta ao response. Me mostre cada arquivo e funcao no caminho." O Claude segue a cadeia inteira.

Usar /init para gerar um CLAUDE.md que documenta a arquitetura, convencoes e padroes do projeto. Isso cria uma "memoria persistente" que toda sessao futura vai carregar automaticamente.

Sem /init, cada nova sessao comeca do zero. Com o CLAUDE.md gerado, o Claude ja sabe as convencoes do projeto, estrutura de diretorios e padroes de codigo desde a primeira mensagem.

Rode /init apos explorar o projeto. O Claude gera um CLAUDE.md com: arquitetura, stack, convencoes de codigo, comandos de build/test e padroes de nomenclatura. Revise e ajuste conforme necessario.

Perguntar ao Claude "por que" decisoes de arquitetura foram tomadas, nao apenas "o que" o codigo faz. Entender a intencao por tras do design e tao importante quanto entender a implementacao.

Saber que existe um cache nao e suficiente. Saber POR QUE existe um cache (performance do banco, limite de API, etc.) e o que previne voce de remover algo essencial por ignorancia.

Prompt: "Por que este modulo usa event sourcing em vez de CRUD direto?", "Por que existe esta camada de cache aqui?", "Qual problema este workaround resolve?" O Claude analisa o contexto e infere razoes.

A abordagem sistematica para entrar num projeto novo: visao geral primeiro, depois fluxos criticos, depois detalhes conforme necessario. Nao tente entender tudo de uma vez.

Onboarding eficiente reduz o tempo ate a primeira contribuicao de semanas para horas. Com Claude, voce pode explorar o codebase de forma interativa em vez de ler documentacao estatica.

Fluxo recomendado: 1) Big picture com Claude 2) /init para gerar CLAUDE.md 3) Trace dos fluxos criticos 4) Primeira tarefa pequena para validar entendimento 5) Expandir conhecimento conforme necessario.

Pedir ao Claude para analisar o codigo e identificar areas sem cobertura de testes: funcoes nao testadas, branches nao cobertas, edge cases ignorados e cenarios de erro sem teste.

Voce nao pode testar o que nao sabe que falta. O Claude analisa o codigo e os testes existentes para mapear exatamente onde estao os gaps. Isso prioriza o esforco de teste.

Prompt: "Analise os testes existentes e o codigo em [diretorio]. Identifique funcoes sem testes, branches nao cobertos e edge cases nao testados. Priorize por risco." O Claude gera um mapa de gaps.

Pedir ao Claude para gerar testes para os gaps identificados. Ele cria testes que seguem os patterns e framework ja usados no projeto (jest, pytest, vitest, etc.).

Escrever testes manualmente e demorado e repetitivo. O Claude gera testes em segundos, cobrindo happy paths, edge cases e cenarios de erro. Voce revisa e ajusta em vez de escrever do zero.

Prompt: "Escreva testes para [funcao/modulo] cobrindo: happy path, input invalido, edge cases e cenarios de erro. Siga o mesmo framework e patterns dos testes existentes." O Claude analisa testes existentes e replica o estilo.

Rodar os testes gerados pelo Claude e verificar que todos passam. Testes que falham precisam ser corrigidos - o Claude pode ter gerado assertions incorretas ou mocks incompletos.

Testes gerados por IA podem ter erros: mocks incorretos, assertions erradas, setup incompleto. Rodar e verificar e essencial antes de considerar a tarefa completa.

Peca: "rode os testes que voce criou e corrija qualquer falha." O Claude executa, analisa erros e corrige. Repita ate todos os testes passarem. Verifique que testes existentes tambem continuam passando.

Rodar o coverage report apos adicionar os novos testes e verificar se a cobertura melhorou. Identificar areas que ainda estao descobertas e decidir se precisam de mais testes.

Coverage quantifica o progresso. Sem metricas, voce nao sabe se os testes novos realmente cobriram o que faltava. O coverage report e seu comprovante de trabalho.

Peca: "rode os testes com coverage e me mostre o relatorio." O Claude executa npm test --coverage / pytest --cov e analisa o resultado. Se a cobertura nao e suficiente, ele sugere mais testes.

Usar Claude Code para TDD: primeiro escrever o teste que falha, depois implementar o codigo que faz o teste passar, depois refatorar. Red-Green-Refactor com IA.

TDD com Claude e extremamente eficiente. Voce descreve o comportamento desejado, Claude escreve o teste, voce valida, e entao Claude implementa o codigo. O teste guia a implementacao.

Prompt: "Escreva um teste para [funcionalidade]. O teste deve falhar porque a funcao ainda nao existe." Depois: "Agora implemente a funcao para passar o teste." Depois: "Refatore mantendo os testes passando."

Principios para testes de qualidade: testes deterministicos, isolamento, nomes descritivos, arrange-act-assert e quando usar mocks vs dados reais.

Testes ruins sao piores que nenhum teste: dao falsa confianca, quebram por motivos errados e sao dificeis de manter. Bons testes documentam o comportamento e protegem contra regressao.

Peca ao Claude: "revise estes testes por boas praticas." Ele verifica: testes deterministicos, sem dependencia de ordem, nomes claros, assertions especificas (nao genericas), e isolamento adequado entre testes.

Pedir ao Claude para revisar suas mudancas antes de criar um PR. Voce pode ser especifico: "revise por seguranca", "revise por performance", ou pedir uma revisao geral completa.

Todo codigo se beneficia de um segundo par de olhos. O Claude identifica patterns problematicos, vulnerabilidades e inconsistencias que voce nao percebe quando esta imerso no codigo.

Prompt: "Revise minhas mudancas desde o ultimo commit. Foque em: bugs potenciais, seguranca, performance e legibilidade." Quanto mais especifico o foco, melhor a qualidade do review.

O slash command /review faz uma revisao automatica do diff atual. Analisa todas as mudancas staged e unstaged procurando problemas de seguranca, bugs, performance e estilo.

/review e mais rapido que escrever um prompt de revisao. Um unico comando e voce tem uma revisao estruturada. Ideal para usar antes de todo /commit e todo /pr.

Digite /review e o Claude analisa o diff completo. Ele retorna: issues encontradas por categoria (bug, seguranca, performance, estilo), severidade e sugestoes de correcao. Use como pre-commit check.

Resolver os problemas apontados na revisao. Voce pode pedir ao Claude para corrigir automaticamente ou decidir caso a caso quais sugestoes aceitar.

Nem todo feedback precisa ser aceito. Mas cada ponto deve ser avaliado. Aprender a triar - aceitar correcoes criticas, discutir sugestoes de estilo, descartar falsos positivos - e uma skill de review.

Prompt: "Corrija os issues de seguranca e os bugs. Para os problemas de estilo, aplique apenas os que fazem sentido pro padrao deste projeto." Voce direciona quais mudancas aplicar.

Rodar /review novamente apos aplicar as correcoes. Verificar que os problemas foram resolvidos e que as correcoes nao introduziram novos issues.

Correcoes podem introduzir novos problemas. Re-review e o loop de feedback que garante que voce nao esta jogando whack-a-mole com bugs. So prossiga quando o review esta limpo.

Rode /review de novo. Se limpo, prossiga. Se novos issues, corrija e repita. O ciclo review > fix > re-review garante qualidade antes do commit e elimina problemas iterativamente.

Pedir revisoes focadas em areas especificas: seguranca (SQL injection, XSS, autenticacao), performance (N+1 queries, memory leaks, algoritmos), ou conformidade (coding standards, patterns).

Revisoes genericas pegam problemas superficiais. Revisoes focadas pegam problemas profundos. Um review de seguranca focado encontra vulnerabilidades que um review geral nao percebe.

Prompts: "Revise este codigo APENAS por vulnerabilidades de seguranca. Procure: injection, XSS, autenticacao bypassada, dados sensiveis expostos." Ou: "Revise por performance: N+1 queries, loops desnecessarios, allocations excessivas."

Uma checklist mental (e do Claude) para validar antes de abrir um PR: testes passando, review limpo, sem console.logs esquecidos, sem TODOs pendentes, sem secrets commitados.

PRs que voltam com comentarios sobre erros basicos desperdicam tempo de todos. A pre-PR checklist elimina os erros mais comuns antes de pedir review humano.

Prompt: "Faca uma checklist pre-PR: testes passam? review limpo? console.logs removidos? TODOs resolvidos? secrets no codigo? imports nao usados? tipos corretos?" O Claude verifica cada item automaticamente.

Antes de criar o PR, organizar os commits: squash se necessario, mensagens claras, commits atomicos. O historico de commits e parte da comunicacao do PR.

Um PR com 47 commits "wip" e "fix typo" dificulta review. Commits bem organizados contam a historia da mudanca e permitem review por commit, nao por arquivo.

Peca ao Claude: "revise meu historico de commits e sugira como organizar para o PR." Ele pode sugerir squash de commits WIP, reordenacao logica, ou manter como esta se ja esta bom.

O slash command /pr cria uma pull request automaticamente: analisa todos os commits, gera titulo, descricao detalhada, e abre o PR no GitHub/GitLab diretamente do terminal.

Criar PRs manualmente exige escrever descricoes, listar mudancas, adicionar contexto. O /pr faz tudo isso automaticamente baseado nos commits e diff, economizando minutos em cada PR.

Digite /pr e o Claude: 1) analisa todos os commits na branch, 2) gera titulo descritivo, 3) cria descricao com contexto, mudancas e impacto, 4) abre o PR via gh cli. Tudo em um comando.

O conteudo que o Claude gera para o PR: titulo conciso, summary das mudancas, motivacao/contexto, lista de arquivos modificados, instrucoes de teste e notas de review.

Entender o que o Claude gera permite ajustar e melhorar. Ele cria uma base excelente, mas voce pode querer adicionar screenshots, links para issues ou contexto que so voce sabe.

O Claude gera: titulo no padrao do repo, descricao com "What" e "Why", lista de mudancas por arquivo, breaking changes se houver, e instrucoes de como testar. E uma PR description profissional automatica.

Revisar a descricao do PR gerada pelo Claude antes de submeter. Verificar que a descricao esta precisa, que o contexto esta correto e que nao falta informacao importante.

O Claude nao sabe sobre conversas no Slack, decisoes em reuniao ou contexto de negocio. Voce precisa adicionar esse contexto humano que torna a PR description realmente util para reviewers.

Verifique: o titulo reflete a mudanca? A descricao explica o "por que"? Links para issues estao corretos? Breaking changes estao documentados? Instrucoes de teste sao claras? Adicione o que falta.

Fazer ajustes finais no PR: adicionar labels, assignees, reviewers, milestone e qualquer metadado que o /pr nao adicionou automaticamente.

Metadata do PR facilita triagem e organizacao. Labels categorizam (bug, feature, refactor), reviewers agilizam o processo, e milestones conectam ao planejamento. O /pr cria o PR, voce personaliza.

Apos o /pr criar o PR, adicione: labels (tipo de mudanca, prioridade), reviewers (quem precisa aprovar), milestone (sprint/release) e linked issues (closes #123). O Claude pode ajudar via gh cli.

Principios para PRs de qualidade: tamanho ideal (200-400 linhas), uma preocupacao por PR, descricao que conta historia, e resposta rapida a review comments.

PRs gigantes nao sao revisadas com cuidado. PRs pequenas e focadas recebem review rapido e de qualidade. O tamanho do PR afeta diretamente a qualidade do feedback que voce recebe.

Regras: PRs < 400 linhas, um proposito por PR, descricao com contexto e instrucoes de teste. Se a feature e grande, divida em PRs menores encadeados. Responda review comments em < 24h.

A forma mais direta de debugar: copiar o erro completo (stack trace, mensagem, contexto) e colar diretamente no Claude Code. Ele analisa o erro no contexto do seu codebase.

O Claude tem acesso ao seu codebase. Quando voce cola um erro, ele nao so interpreta o stack trace mas navega ate os arquivos mencionados e entende o contexto real da falha.

Cole o erro completo, nao so a mensagem. Inclua: stack trace, linha do erro, tipo de excecao, e contexto de quando aconteceu. Prompt: "Este erro acontece quando [acao]. Aqui esta o stack trace: [cole tudo]."

Usar pipe para enviar logs diretamente ao Claude: tail -f app.log | claude -p "analise estes logs". Ideal para logs longos que nao cabem em um paste manual.

Logs de producao podem ter milhares de linhas. Pipe permite filtrar e enviar apenas o relevante: tail -100 app.log | grep ERROR | claude -p "o que esta causando estes erros?".

Exemplos: cat error.log | claude -p "analise". tail -500 app.log | grep -A5 "Exception" | claude -p "identifique o padrao de erro". Combine grep para filtrar antes de enviar ao Claude.

Pedir ao Claude para tracar a causa raiz partindo do erro: seguir o stack trace, analisar o fluxo de dados, identificar onde o estado ficou inconsistente e por que.

O Claude traca automaticamente: le o arquivo da linha do erro, segue a cadeia de chamadas, verifica inputs e outputs de cada funcao. E como ter um debugger que entende semantica.

Prompt: "Trace a causa raiz deste erro. Comece pela linha do stack trace e siga a cadeia de chamadas ate encontrar onde o dado ficou invalido." O Claude navega pelos arquivos e apresenta a cadeia causal.

Aplicar a correcao baseada na causa raiz identificada. O Claude edita os arquivos necessarios com a mudanca minima para resolver o problema.

Depois de entender a causa raiz, a correcao deve ser cirurgica. Mudancas minimas sao mais faceis de revisar, testar e reverter se necessario. O Claude aplica exatamente o necessario.

Prompt: "Aplique a correcao minima para resolver a causa raiz identificada." Revise o diff. Se a correcao e mais complexa do que esperado, questione se a causa raiz esta realmente correta.

Verificar que o fix realmente resolveu o problema: reproduzir o cenario que causava o erro e confirmar que agora funciona. Rodar testes relacionados.

Um fix que nao e verificado nao e um fix. Reproduza o erro original e confirme que nao acontece mais. Rode a suite de testes para garantir que nada mais quebrou.

Peca: "rode o cenario que causava o erro e confirme que esta resolvido. Depois rode todos os testes." O Claude executa o teste de verificacao e a suite completa, reportando os resultados.

Tecnicas avancadas: adicionar logging temporario com Claude, usar breakpoints estrategicos, debugar race conditions e problemas de timing.

Nem todo bug tem stack trace claro. Bugs intermitentes, race conditions e problemas de state precisam de abordagens especializadas. O Claude pode sugerir e implementar estrategias de debugging avancadas.

Prompt: "Adicione logging temporario estrategico para rastrear o valor de [variavel] ao longo do fluxo." Ou: "Este bug e intermitente - sugira uma estrategia de debugging para race conditions." Remova logs temporarios apos resolver.

Usar plan mode (Shift+Tab) para mapear TODOS os arquivos afetados pela refatoracao antes de tocar em qualquer codigo. O Claude cria um inventario completo de mudancas necessarias.

Refatoracao multi-arquivo sem plano e caos. Voce muda um arquivo e quebra 15 outros. O plano mostra todas as dependencias, ordem de execucao e riscos antes de comecar.

Prompt em plan mode: "Planeje a refatoracao de [X] para [Y]. Liste TODOS os arquivos afetados, a ordem de mudanca e dependencias entre eles." O Claude gera um plano de migracao completo.

Revisar criticamente o escopo da refatoracao: quantos arquivos, quais sao criticos, qual a ordem de dependencia, e se o escopo nao cresceu alem do necessario.

Scope creep e o inimigo de refatoracoes grandes. O Claude pode incluir mudancas "nice to have" que nao sao necessarias agora. Revise e corte o escopo para o minimo viavel.

Pergunte: "Este arquivo realmente precisa mudar nesta fase?" e "Podemos dividir esta refatoracao em fases menores?" Priorize mudancas criticas e adie as opcionais para outro PR.

Dividir a refatoracao em batches (lotes) de 3-5 arquivos por vez. Cada batch e uma unidade completa que pode ser testada independentemente antes de prosseguir.

Mudar 50 arquivos de uma vez e impossivel de debugar se algo quebra. Em batches de 5, voce sabe exatamente qual batch introduziu o problema. E mais seguro e controlavel.

Prompt: "Execute o batch 1 do plano: arquivos [lista]. Aplique as mudancas e me avise quando terminar." Teste. Commit. Proximo batch. Cada batch e um checkpoint de seguranca.

Rodar todos os testes apos cada batch de mudancas. Se testes falham, corrigir ANTES de seguir para o proximo batch. Nunca acumular batches sem validacao.

Testar apos cada batch mantem o projeto funcional durante toda a migracao. Se voce acumula 5 batches sem testar e algo quebra, encontrar a causa em 25 arquivos e pesadelo.

Fluxo: batch > test > fix se necessario > commit > proximo batch. Peca: "rode todos os testes apos este batch." Se falhar: "corrija as falhas mantendo as mudancas do batch." Nunca pule testes.

Depois de todos os batches, fazer uma varredura final: verificar que nao ficou nenhuma referencia antiga, imports quebrados, ou inconsistencias entre os arquivos migrados.

Batches podem deixar inconsistencias entre si: um arquivo usa a interface nova, outro ainda referencia a antiga. A varredura final pega esses gaps que testes individuais nao captam.

Prompt: "Faca uma varredura final: procure por referencias antigas a [nome antigo], imports quebrados, tipos inconsistentes e qualquer artefato da refatoracao que ficou para tras." O Claude varre todo o projeto.

Usar /compact estrategicamente durante migracoes longas para liberar contexto sem perder o plano de migracao. Compacte preservando o status: quais batches foram feitos, quais faltam.

Migracoes longas consomem muito contexto. Sem /compact, voce atinge o limite e o Claude comeca a esquecer o plano. Com /compact estrategico, voce mantem a sessao funcional durante toda a migracao.

Prompt para /compact: "Compacte preservando: o plano de migracao, quais batches ja foram concluidos (1-3), quais faltam (4-7), e quaisquer decisoes importantes tomadas." O Claude compacta mantendo o contexto critico.