Prompts do Claude Code: 25 prompts prontos para copiar e como escrever os seus próprios

Clientes que utilizam um cupom vencido recebem um erro 500 no momento do checkout. Analise o arquivo @src/checkout/coupons.ts e seus testes. O comportamento esperado é a exibição de uma mensagem de cupom inválido, sem que seja criado um pedido. Escreva um teste que falhe e reproduza o erro; em seguida, corrija-o sem alterar o comportamento de cupons válidos. Execute o [comando de teste de checkout] e mostre os resultados antes e depois. Se não conseguir reproduzir o erro, relate o que verificou antes de alterar a implementação.

Adicione um seletor de datas ao [caminho do formulário de reserva]. Siga as convenções de componentes e validação em @src/components/TimeSelect.tsx. Os usuários devem poder selecionar [datas permitidas], enquanto [datas indisponíveis] permanecem desativadas. Não adicione bibliotecas. Execute o [comando de teste do componente] e o [comando de verificação de tipos] e relate quaisquer critérios que essas verificações não abranjam.

Divida o arquivo @src/reports/export.py em funções menores, preservando suas entradas, o formato de saída e o comportamento em caso de erro. Execute o [comando de teste de exportação] antes de editar e relate quaisquer falhas existentes. Após a refatoração, execute os testes novamente e mostre os dois resultados. Não altere a interface pública nem arquivos não relacionados.

“O Claude testa cada alteração que eu envio para claude.ai/code usando a extensão do Claude para o Chrome. Ele abre um navegador, testa a interface do usuário e repete o processo até que o código funcione e a experiência do usuário seja satisfatória. ”

Analise o arquivo README, a configuração do projeto e a estrutura de diretórios de nível superior deste repositório. Siga as referências apenas quando necessário para explicar: O que o aplicativo faz; Seus principais pontos de entrada e componentes; Onde os testes estão localizados e quais comandos o repositório define para executá-los. Cite os caminhos dos arquivos que sustentam sua explicação. Distinga o comportamento documentado de suas próprias inferências e sinalize tudo o que não for possível determinar. Não leia arquivos de segredos ou de ambiente, não inspecione dependências instaladas nem altere nenhum arquivo. Conclua indicando os três arquivos que eu deveria ler primeiro e explique o motivo.

Analise o histórico do Git de [arquivo, função ou classe], com foco em [comportamento ou questão de projeto]. Identifique os commits que introduziram ou alteraram substancialmente esse comportamento. Para cada commit relevante, forneça seu hash, resuma a alteração e explique qualquer justificativa documentada na mensagem do commit ou na discussão vinculada à qual você tenha acesso. Identifique as razões inferidas como “inferências”. Se o histórico não explicar uma decisão, indique isso. Não modifique arquivos nem o histórico do Git.

Rastreie o que acontece quando ocorre [ação do usuário ou evento do sistema], começando em [rota, manipulador ou pasta conhecida]. Acompanhe as chamadas relevantes passando pela validação, lógica de negócios e quaisquer gravações no banco de dados ou solicitações externas. Liste os arquivos e funções na ordem de execução, com referências de linha, quando disponíveis. Explique os principais caminhos de falha e identifique os testes existentes que cobrem o fluxo. Sinalize qualquer conexão que você não consiga confirmar a partir do código. Não execute o fluxo, não chame serviços externos nem edite arquivos.

Planeje como implementar [recurso] na [área do repositório]. O comportamento esperado é [requisitos], e estas áreas devem permanecer inalteradas: [restrições]. Inspecione o código relevante e os testes existentes. Identifique os arquivos que precisam ser alterados, a ordem de implementação e quaisquer riscos de compatibilidade ou migração de dados. Mapeie cada requisito para um teste proposto ou outra etapa de verificação. Liste separadamente as questões não resolvidas e as suposições. Não implemente o recurso ainda. Envie o plano para que eu analise.

Quero desenvolver [breve descrição] para [usuários e caso de uso]. Leia primeiro [arquivos ou requisitos relevantes] e, em seguida, use AskUserQuestion para esclarecer decisões que possam afetar significativamente a implementação. Concentre-se em casos extremos, tratamento de dados, permissões, comportamento esperado da interface do usuário e compromissos. Não faça perguntas cujas respostas já estejam no contexto fornecido. Assim que as principais decisões forem resolvidas, elabore um rascunho de especificação abrangendo requisitos, critérios de aceitação, restrições e o que está fora do escopo. Indique quaisquer suposições remanescentes. Mostre-me a especificação antes de salvá-la em [caminho da especificação] e não sobrescreva um arquivo existente sem aprovação.

Avalie o impacto da alteração de [função, componente ou interface] do [comportamento atual] para o [comportamento proposto]. Pesquise no [escopo do repositório ou diretório] sua definição, chamadores diretos, importações e testes relacionados. Liste os arquivos que provavelmente precisarão de alterações e explique como cada um poderia ser afetado, com referências a arquivos e linhas, quando disponíveis. Sinalize chamadas resolvidas dinamicamente, consumidores externos ou outras dependências que você não possa verificar. Identifique quaisquer questões de compatibilidade que precisem de resposta antes da implementação. Não altere os arquivos; envie a avaliação de impacto e aguarde minha revisão.

Adicione [recurso] ao [arquivo ou página] com este comportamento: [critérios de aceitação]. Inspecione a [implementação existente] e siga suas convenções para obtenção de dados, tratamento de erros e organização de componentes. Use apenas bibliotecas já instaladas no projeto. Mantenha as alterações dentro do [escopo] e preserve o [comportamento existente ou a interface pública]. Adicione ou atualize testes para os critérios de aceitação. Execute o [comando de teste] e o [comando de verificação de tipo ou lint] e, em seguida, relate os arquivos alterados, os resultados e quaisquer verificações que não tenham sido concluídas. Se o padrão existente entrar em conflito com um requisito, explique o conflito antes de prosseguir.

Implemente [nome da função] no [arquivo] para atender aos [requisitos]. Aborde o [caso normal], o [caso extremo] e o [comportamento em caso de entrada inválida]. Execute primeiro o [comando de teste relevante] e relate quaisquer falhas existentes. Escreva testes para o comportamento solicitado e, em seguida, execute-os antes da implementação. Confirme se os novos testes falham pelo motivo esperado. Implemente a função e execute os testes novamente. Não enfraqueça as asserções, não pule testes nem altere o comportamento esperado para que eles sejam aprovados. Se os requisitos entrarem em conflito com os testes existentes, pare e explique o conflito. Mostre os resultados antes e depois.

Implemente o design anexado em [componente ou página], utilizando os componentes e estilos existentes do projeto. Preserve o [comportamento exigido] e evite alterações fora do [escopo]. Use o [navegador configurado ou ferramenta de captura de tela] para capturar a [rota local] nas [dimensões da janela de visualização] com [dados de teste e estado da interface do usuário]. Se a ferramenta ou o aplicativo não estiver disponível, relate o que é necessário, em vez de alegar uma verificação visual. Compare a captura com a referência, concentrando-se no [layout, espaçamento, tipografia ou outros critérios de aceitação]. Faça até [número] rodadas de correção e, em seguida, relate as diferenças restantes. Não altere a imagem de referência. Execute [testes de componentes relevantes] e [verificação de tipo ou comando de compilação]. Inclua a captura de tela e os resultados reais da verificação em seu resumo.

Os usuários enfrentam [sintoma] quando [gatilho ou entrada]. O comportamento esperado é [resultado esperado]. Comece inspecionando [pasta, função ou fluxo] e os testes relacionados. Crie um teste com falha que reproduza o comportamento relatado. Se não for possível reproduzi-lo, explique o que você verificou e quais informações estão faltando antes de alterar a implementação. Uma vez reproduzido, corrija a causa sem alterar [comportamento que deve permanecer intacto]. Execute o novo teste e [comando de teste relacionado]. Mostre a falha antes da correção, os resultados após a correção e quaisquer falhas remanescentes.

[Comando de compilação] falha no [ambiente local ou de CI] com esta saída: [log de erros expurgado]. Inspecione o código e a configuração relevantes para identificar a causa. Verifique se há diferenças no ambiente ou nas dependências caso a falha não se reproduza localmente. Faça a menor alteração possível que resolva a causa. Não desative verificações, suprime erros, pule testes ou flexibilize as configurações do compilador apenas para obter uma compilação aprovada. Execute a compilação novamente após a alteração. Se ela ainda falhar após [número] tentativas de correção, pare e relate o que você tentou, o erro atual e a próxima etapa de diagnóstico. Resuma a causa e inclua o resultado real da compilação.

Ajude-me a identificar um bug antes de propor uma correção. Comportamento observado: [o que acontece] Comportamento esperado: [o que deveria acontecer] Quando ocorre: [condições ou frequência] O que já tentei: [etapas e resultados] Faça uma pergunta por vez, escolhendo aquela que melhor diferencie as causas prováveis. Não repita perguntas cujas respostas já estejam nas informações fornecidas. Quando houver evidências suficientes, resuma a explicação mais provável, o que ainda permanece incerto e o menor teste que poderia confirmar ou descartar essa hipótese. Não edite arquivos ainda.

Use um subagente para revisar [diferenças ou ramificação em comparação com a base] em relação ao [plano aprovado ou arquivo de requisitos]. Se os requisitos estiverem ausentes ou forem ambíguos, relate isso antes de avaliar a integridade. Verifique se cada requisito foi implementado, se os casos de borda relevantes possuem testes e se quaisquer alterações estão fora do escopo acordado. Inspecione o código ao redor, quando necessário, para compreender a diferença. Relate problemas de correção e requisitos não atendidos com referências a arquivos e linhas, seu impacto e as evidências que sustentam cada constatação. Separe os problemas confirmados das questões não resolvidas. Não invente constatações para preencher uma cota nem inclua preferências de estilo não relacionadas. Não edite arquivos.

Analise [arquivos ou comparações] em busca de riscos de injeção, verificações de autorização ausentes, segredos expostos e tratamento inseguro de entradas do usuário. Inspecione os chamadores relevantes e a lógica de validação antes de relatar uma descoberta. Para cada problema, identifique o arquivo e as linhas afetadas, as condições necessárias para acioná-lo, o impacto provável e uma correção sugerida. Distinga um caminho vulnerável confirmado de uma suspeita que precise de testes adicionais. Não reproduza valores confidenciais no relatório, não modifique arquivos nem faça testes em serviços em produção. Indique quais áreas você revisou e o que permanece fora do escopo.

Resuma como você verificou a alteração concluída em relação aos [critérios de aceitação]. Para cada critério, liste a verificação realizada, o comando exato (quando aplicável) e o resultado observado. Inclua a saída relevante, com segredos e dados confidenciais ocultados. Identifique separadamente quaisquer falhas pré-existentes. Distinga claramente as verificações que foram aprovadas, as que falharam e as que não foram executadas. Explique quaisquer verificações ignoradas ou limites na cobertura. Não descreva a alteração inteira como verificada se alguns critérios permanecerem sem verificação.

Reestruture [arquivo ou módulo] para [objetivo específico, como dividir uma função grande ou remover callbacks aninhados]. Preserve sua interface pública, valores de retorno, comportamento em caso de erro e efeitos colaterais. Execute [comando de teste relevante] antes da edição para estabelecer uma linha de base. Se houver falha, relate as falhas antes de prosseguir. Identifique qualquer comportamento que os testes existentes não abranjam e adicione testes específicos onde for necessário. Faça a reestruturação sem alterações não relacionadas ou novas dependências. Não enfraqueça as asserções existentes para acomodar a implementação. Reexecute os testes e [comando de verificação de tipo ou lint]. Mostre os resultados antes e depois, resuma as alterações estruturais e sinalize qualquer comportamento que não tenha sido possível verificar.

Identifique os usos da [API ou biblioteca antiga] dentro do [escopo do diretório], excluindo arquivos gerados e de fornecedores. Liste os arquivos afetados e quaisquer configurações compartilhadas ou dependências que a migração possa impactar. Proponha três arquivos representativos para uma migração piloto para a [nova API ou versão], utilizando o [guia de migração ou exemplo existente]. Explique por que você os selecionou e sinalize quaisquer alterações de comportamento necessárias. Aguarde minha aprovação antes de editar. Após a aprovação, migre apenas os arquivos piloto e quaisquer dependências compartilhadas explicitamente aprovadas. Execute [testes relevantes] e [comando de compilação ou verificação de tipos]. Não expanda a migração para outros arquivos. Relate as diferenças, os resultados dos testes, os problemas de compatibilidade e quaisquer alterações necessárias na abordagem de migração. Interrompa para revisão antes de continuar com os arquivos restantes.

Inspecione o branch atual, o status do Git e o diff para [recurso ou correção]. Identifique os arquivos pertencentes a essa alteração e liste separadamente os arquivos não relacionados ou não rastreados. Elabore uma mensagem de commit seguindo o formato dos últimos 10 commits. Prepare uma descrição da pull request abordando o que mudou, o motivo, os testes efetivamente executados e quaisquer limitações remanescentes. Mostre a lista de arquivos proposta, a mensagem de commit e a descrição da solicitação de pull antes de preparar ou publicar qualquer coisa. Aguarde minha aprovação. Após a aprovação, prepare apenas os arquivos acordados, faça o commit no [ramo de recurso], envie para [remoto] e abra uma solicitação de pull no [ramo base]. Não altere commits existentes, não faça push forçado nem mescle. Envie o hash do commit e o link da solicitação de pull.

Elabore uma seção README para [módulo] voltada para [leitor, como um engenheiro de back-end que está ingressando no projeto]. Aborde os pré-requisitos, a configuração, os três comandos que serão mais utilizados e os erros comuns abordados pelo código ou pela documentação existente. Verifique os nomes dos comandos e as opções em relação aos [scripts do pacote, Makefile, ajuda da CLI ou configuração de CI]. Sinalize tudo o que não for possível confirmar. Teste comandos locais seguros no [ambiente de teste], quando disponível. Antes de executar comandos que instalem dependências, excluam arquivos, migrem dados, façam implantação ou acessem serviços externos, explique seus efeitos e peça aprovação. Distinga claramente os comandos que você executou com sucesso daqueles verificados apenas em relação à configuração ou à documentação. Mostre a seção README proposta antes de editar [caminho da documentação] e preserve o conteúdo não relacionado.

Analise [caminho para CLAUDE.md] em relação à estrutura atual do repositório, aos scripts e às convenções. Não edite o arquivo ainda. Identifique instruções desatualizadas, duplicatas, contradições e regras que possam ser inferidas de forma confiável a partir do código. Explique cada remoção proposta, em vez de cortar instruções apenas para encurtar o arquivo. Sugira comandos de compilação ou teste ausentes somente quando puder verificá-los nos scripts do projeto, em um Makefile, na configuração de CI ou na documentação existente. Cite a fonte de cada adição. Envie um diff proposto que preserve as restrições importantes do projeto. Sinalizem instruções específicas de tarefas que se encaixariam melhor em uma regra no escopo de uma skill ou de um caminho e aguardem a aprovação antes de aplicar as alterações.

Proponha um gancho de comando do Claude Code que execute [comando do formatador existente] após alterações feitas com “Editar” ou “Escrever” em [padrões de arquivo]. Inspecione primeiro a configuração existente em claude/settings.json e a configuração do formatador. Use a configuração PostToolUse apropriada para a versão instalada do Claude Code. Formate apenas o arquivo afetado, lide com os caminhos com segurança e exclua [arquivos gerados ou outros caminhos excluídos]. Não instale dependências nem substitua ganchos existentes. Mostre a comparação das configurações propostas e explique como as falhas do formatador serão relatadas. Aguarde a aprovação antes de aplicá-la. Após a aprovação, teste-a com um arquivo temporário no projeto e relate o resultado. Indique quais caminhos de edição ela abrange e quais não, incluindo alterações feitas por meio de comandos de shell.

Consulte [ferramenta] –help e a ajuda para os subcomandos relevantes para [tarefa]. Não instale a ferramenta se ela estiver faltando; em vez disso, relate esse pré-requisito. Proponha os comandos exatos necessários para concluir a tarefa. Explique suas entradas, saídas e se eles gravam arquivos, alteram recursos remotos ou usam credenciais. Inclua uma opção de simulação, caso a ferramenta a documente. Sinalize configurações ou permissões ausentes e peça esclarecimentos, em vez de adivinhar nomes de recursos ou destinos. Aguarde a aprovação antes de executar os comandos da tarefa. Após a aprovação, execute apenas os comandos acordados e relate seus resultados reais, incluindo quaisquer erros ou etapas incompletas.

Compare [invoices.csv] e [payments.csv] usando [ID da fatura ou chave de correspondência]. Não modifique os arquivos de origem. Aplique estas regras: [moeda e tolerância de arredondamento], [alocação de pagamentos parciais] e [tratamento de reembolsos, créditos e pagamentos a maior]. Se uma regra estiver faltando ou se uma correspondência for ambígua, sinalize-a em vez de atribuir o pagamento automaticamente. Preserve os IDs das linhas de origem. Para cada fatura, mostre o valor faturado, os pagamentos aplicados e o saldo restante. Relate IDs duplicados, faturas não correspondentes, pagamentos não correspondentes e saldos fora da tolerância. Reconciliar os totais de faturas e pagamentos separadamente. Contabilize cada linha de origem sem contagem dupla; se um pagamento for dividido entre faturas, mostre cada alocação e confirme se as alocações não excedem o valor do pagamento. Grave os resultados em [novos caminhos de saída] e resuma as exceções que exigem revisão.

Escreva um script que resuma o arquivo [export.csv] para o período de [data e hora de início, inclusive] até [data e hora de término, exclusiva], usando o [fuso horário] e a [coluna de data]. Agrupe os registros de acordo com as [regras de categoria] e calcule as [métricas exigidas]. Trate IDs duplicados e valores ausentes de acordo com as [regras]. Não modifique o arquivo de entrada. Execute o script no [arquivo de entrada exato]. Relate o número de linhas incluídas e excluídas, os totais por categoria e os registros que não puderam ser classificados. Compare os resultados para [três categorias] com as contagens verificadas independentemente no [arquivo de referência]. Se essas contagens não estiverem disponíveis, indique que a validação independente ainda está pendente. Mostre as discrepâncias e salve o relatório no [novo caminho de saída].

Leia [arquivos ou pasta especificados] e elabore um rascunho de [tipo e extensão do documento] para [público-alvo], abordando [questões ou tópicos]. Fundamente cada afirmação factual com o nome do arquivo e uma referência à página, seção ou linha, quando disponível. Distinga citações diretas de paráfrases e não trate uma proposta ou documento desatualizado como uma decisão atual confirmada. Sinalize fontes conflitantes, informações ausentes e afirmações que você não consiga verificar. Não preencha lacunas com suposições nem edite os arquivos de origem. Entregue o rascunho com suas referências e uma breve lista de questões não resolvidas para o revisor.

Para adaptar um modelo, substitua seus espaços reservados pelos detalhes do seu projeto e decida o que o Claude deve fazer antes de fazer as alterações. Siga estas etapas para preparar a solicitação e revisar o resultado.

Para uma alteração pequena e bem definida, você pode pedir ao Claude para implementá-la diretamente. Para códigos desconhecidos, alterações em vários arquivos ou requisitos não resolvidos, comece com um plano.

Pressione Shift+Tab até que o modo Plan apareça ou inicie o Claude Code com o comando claude --permission-mode plan. Nesse modo, o Claude pode inspecionar arquivos e executar comandos somente de leitura sem editar seu código-fonte. Analise os arquivos, dependências e testes propostos antes de aprovar a implementação. Pressione Ctrl+G para abrir o plano proposto em seu editor.

Forneça ao Claude as evidências necessárias para compreender a tarefa: uma referência de arquivo, um log de erros limpo, uma captura de tela ou um documento de requisitos. Use @ seguido do caminho do arquivo para incluir o conteúdo desse arquivo.

Escolha o menor conjunto útil de fontes. Incluir um log ou diretório inteiro pode adicionar material irrelevante e consumir contexto. Remova credenciais e dados confidenciais antes de compartilhar logs e verifique se o Claude possui as ferramentas necessárias para acessar quaisquer URLs de documentação que você fornecer.

Por exemplo, o comando `cat error.log | claude -p "Explique este erro"` envia um log por meio de uma solicitação não interativa. Use-o somente após verificar o conteúdo do arquivo. Esse é o valor prático da IA contextual: fornecer ao modelo informações relevantes para a tarefa.

Ao adicionar um recurso, identifique um componente ou função semelhante no repositório. Indique ao Claude quais convenções devem ser seguidas, como o cliente da API, a lógica de validação, o tratamento de erros ou a estrutura de testes.

“Veja como @src/widgets/Weather.tsx busca e armazena dados em cache” fornece ao Claude uma referência concreta. Indique também quaisquer diferenças exigidas pelo novo recurso, para que ele não copie comportamentos que não sejam mais adequados. Essas convenções devem refletir o fluxo de trabalho de desenvolvimento de software da sua equipe.

Para alterações no código, especifique o comando relevante de teste, compilação ou lint e o comportamento que ele deve verificar. Para pesquisas, solicite referências de arquivos ou IDs de commit. Para trabalhos na interface do usuário, forneça uma imagem de referência e uma forma configurada de capturar a implementação na mesma janela de visualização.

Peça ao Claude para relatar o que ele realmente verificou, incluindo falhas e verificações ignoradas. Verifique se as evidências atendem aos requisitos; uma compilação bem-sucedida não garante que todos os comportamentos solicitados funcionem.

Para tarefas mais longas, o Claude Code também oferece uma condição /goal e ganchos de parada (Stop hooks). O avaliador de metas analisa as evidências que surgem na conversa, em vez de inspecionar arquivos ou executar testes de forma independente. Um gancho de parada configurado pode bloquear a conclusão, mas há limites para bloqueios repetidos. Nenhum dos dois substitui testes adequados e a revisão humana.

Se as correções repetidas não estiverem resolvendo um problema, pare e identifique o que ficou pouco claro na solicitação original. Salve as descobertas úteis, o status atual do Git e o trabalho restante antes de limpar a conversa.

O guia de melhores práticas da Anthropic recomenda recomeçar do zero após duas correções malsucedidas na mesma questão. Use /clear e, em seguida, forneça um prompt revisado que inclua o que você aprendeu. Limpar a conversa não desfaz as alterações nos arquivos.

Pressione Esc para interromper uma resposta em execução. Com o campo de entrada vazio, pressione Esc duas vezes para abrir o menu de retrocesso e escolher o que restaurar. O retrocesso não desfaz todos os efeitos externos; portanto, use checkpoints do Git e procedimentos de recuperação separados para alterações em bancos de dados ou serviços remotos.

Salve orientações para todo o projeto no arquivo CLAUDE.md, procedimentos repetíveis nas habilidades e instruções para arquivos específicos em regras com escopo de caminho. Use ganchos para ações vinculadas a eventos específicos, como executar um formatador após uma edição.

Escolha com base no momento em que a instrução deve ser aplicada:

Um requisito para um recurso geralmente deve constar na instrução da tarefa ou na especificação correspondente, e não no arquivo CLAUDE.md. Adicionar instruções temporárias a um arquivo que abrange todo o projeto torna mais difícil distingui-las das convenções que devem ser aplicadas em todo o repositório.

Por exemplo, mantenha o comando de teste do projeto no arquivo CLAUDE.md, coloque convenções específicas de componentes em uma regra com escopo de caminho e salve um procedimento de revisão recorrente como uma habilidade. Revise esses arquivos quando os comandos ou convenções forem alterados, da mesma forma que você faria com qualquer outra documentação do projeto.

As instruções, o arquivo CLAUDE.md e o guia de habilidades orientam o comportamento do Claude; eles não garantem que uma instrução será seguida. Os hooks podem executar verificações em eventos configurados, mas sua confiabilidade depende do tipo de hook e da implementação.

Um gancho de comando executa um script. Um prompt ou gancho de agente depende do julgamento de um modelo. Conforme explica o guia de melhores práticas da Anthropic: “Um prompt ou gancho de agente solicita que outro modelo decida, portanto, também não é determinístico.” Para uma regra que deva ser aplicada, use controles de permissão adequados e teste o comando ou gancho HTTP relevante, incluindo como ele lida com falhas.

Subagentes personalizados são outra forma de organizar tarefas recorrentes. Defina um especialista em `claude/agents/` quando for necessária uma função de revisão específica ou um escopo de ferramenta distinto, em vez de adicionar todas as instruções do especialista à sessão principal. Esses guias sobre o melhor modelo do Claude para o trabalho e os tipos de agentes de IA fornecem contexto adicional.

Se sua equipe mantém prompts em vários produtos de IA, confira estas ferramentas de engenharia de prompts para gerenciar bibliotecas além do Claude Code.

Quando uma sessão produz um resultado incompleto ou inadequado, verifique se a solicitação deixou decisões importantes sem solução. Esses cinco erros podem tornar o trabalho mais difícil de diagnosticar e revisar.

“Investigue o repositório” dá ao Claude poucas orientações sobre quais arquivos são relevantes ou quando parar. Você pode receber um resumo genérico sem uma resposta para o problema que motivou a solicitação.

Nomeie o comportamento ou a decisão que você precisa entender, identifique um ponto de partida e defina o resultado esperado. Por exemplo: “Rastreie como esse endpoint verifica as permissões e cite as funções relevantes.” Se você usar subagentes, atribua a cada um deles uma pergunta delimitada, em vez de delegar a mesma busca irrestrita.

Alternar entre um recurso, um bug não relacionado e uma solicitação de documentação faz com que a conversa mantenha um contexto que pode não se aplicar à tarefa atual. Referências como “aquele arquivo” ou “a abordagem anterior” tornam-se ambíguas.

Use sessões separadas para trabalhos não relacionados. Se várias sessões forem editar o repositório, use árvores de trabalho do Git separadas para que elas não modifiquem o mesmo diretório de trabalho. A propósito, o comando /btw do Claude Code mantém a troca de mensagens fora do histórico principal da conversa.

Uma compilação pode ser aprovada mesmo que um recurso não funcione corretamente. Um conjunto de testes pode ser aprovado porque nunca testou a entrada que causaria falha. Pedir ao Claude para “executar os testes” não determina qual requisito esses testes verificam.

Mapeie os critérios de aceitação para verificações específicas. Para a correção de um bug, solicite comprovação de que o teste de reprodução falhou antes da alteração e foi aprovado depois. Mantenha os critérios não testados visíveis, em vez de considerar um comando bem-sucedido como verificação de toda a alteração.

Um arquivo CLAUDE.md em constante expansão pode conter comandos desatualizados, regras duplicadas e instruções que contradizem os requisitos específicos da tarefa. Adicionar uma redação mais enfática não resolve esses conflitos.

Revise o arquivo em relação ao repositório atual. Remova orientações obsoletas, esclareça regras conflitantes e transfira instruções de aplicação restrita para regras ou habilidades com escopo de caminho. Se um requisito precisar ser aplicado, configure e teste os controles apropriados, em vez de depender de lembretes repetidos.

Uma revisão pode identificar, ao mesmo tempo, defeitos reais, questões duvidosas e sugestões opcionais de refatoração. Aplicar todas as sugestões pode ampliar a alteração sem melhorar o comportamento solicitado.

Solicite as evidências e o impacto por trás de cada constatação. Priorize problemas de correção e requisitos não atendidos, investigue alegações duvidosas e mantenha melhorias não relacionadas fora da comparação atual. Um revisor deve ser capaz de relatar que não há constatações passíveis de ação quando as evidências apoiarem essa conclusão.

Para adaptar um modelo, substitua seus espaços reservados pelos detalhes do seu projeto e decida o que o Claude deve fazer antes de fazer as alterações. Siga estas etapas para preparar a solicitação e revisar o resultado.

Para uma alteração pequena e bem definida, você pode pedir ao Claude para implementá-la diretamente. Para códigos desconhecidos, alterações em vários arquivos ou requisitos não resolvidos, comece com um plano.

Pressione Shift+Tab até que o modo Plan apareça ou inicie o Claude Code com o comando claude --permission-mode plan. Nesse modo, o Claude pode inspecionar arquivos e executar comandos somente de leitura sem editar seu código-fonte. Analise os arquivos, dependências e testes propostos antes de aprovar a implementação. Pressione Ctrl+G para abrir o plano proposto em seu editor.

Forneça ao Claude as evidências necessárias para compreender a tarefa: uma referência de arquivo, um log de erros sanitizado, uma captura de tela ou um documento de requisitos. Use @ seguido do caminho do arquivo para incluir o conteúdo desse arquivo.

Escolha o menor conjunto útil de fontes. Incluir um log ou diretório inteiro pode adicionar material irrelevante e consumir contexto. Remova credenciais e dados confidenciais antes de compartilhar logs e verifique se o Claude possui as ferramentas necessárias para acessar quaisquer URLs de documentação que você fornecer.

Por exemplo, o comando `cat error.log | claude -p "Explique este erro"` envia um log por meio de uma solicitação não interativa. Use-o somente após verificar o conteúdo do arquivo. Esse é o valor prático da IA contextual: fornecer ao modelo informações relevantes para a tarefa.

Ao adicionar um recurso, identifique um componente ou função semelhante no repositório. Indique ao Claude quais convenções devem ser seguidas, como o cliente da API, a lógica de validação, o tratamento de erros ou a estrutura de testes.

“Veja como @src/widgets/Weather.tsx busca e armazena dados em cache” fornece ao Claude uma referência concreta. Indique também quaisquer diferenças exigidas pelo novo recurso, para que ele não copie comportamentos que não sejam mais adequados. Essas convenções devem refletir o fluxo de trabalho de desenvolvimento de software da sua equipe.

Para alterações no código, especifique o comando relevante de teste, compilação ou lint e o comportamento que ele deve verificar. Para pesquisas, solicite referências de arquivos ou IDs de commit. Para trabalhos na interface do usuário, forneça uma imagem de referência e uma forma configurada de capturar a implementação na mesma janela de visualização.

Peça ao Claude para relatar o que ele realmente verificou, incluindo falhas e verificações ignoradas. Verifique se as evidências atendem aos requisitos; uma compilação aprovada não garante que todos os comportamentos solicitados funcionem.

Para tarefas mais longas, o Claude Code também oferece uma condição /goal e ganchos de parada (Stop hooks). O avaliador de metas analisa as evidências que surgem na conversa, em vez de inspecionar arquivos ou executar testes de forma independente. Um gancho de parada configurado pode bloquear a conclusão, mas há limites para bloqueios repetidos. Nenhum dos dois substitui testes adequados e a revisão humana.

Se as correções repetidas não estiverem resolvendo um problema, pare e identifique o que ficou pouco claro na solicitação original. Salve as descobertas úteis, o status atual do Git e o trabalho restante antes de limpar a conversa.

O guia de melhores práticas da Anthropic recomenda recomeçar do zero após duas correções malsucedidas na mesma questão. Use /clear e, em seguida, forneça um prompt revisado que inclua o que você aprendeu. Limpar a conversa não desfaz as alterações nos arquivos.

Pressione Esc para interromper uma resposta em execução. Com o campo de comando vazio, pressione Esc duas vezes para abrir o menu de retrocesso e escolher o que restaurar. O retrocesso não desfaz todos os efeitos externos; portanto, use checkpoints do Git e procedimentos de recuperação separados para alterações em bancos de dados ou serviços remotos.

Salve orientações para todo o projeto no arquivo CLAUDE.md, procedimentos repetíveis nas habilidades e instruções para arquivos específicos em regras com escopo de caminho. Use ganchos para ações vinculadas a eventos específicos, como executar um formatador após uma edição.

Escolha com base no momento em que a instrução deve ser aplicada:

Um requisito para um recurso geralmente deve constar na instrução da tarefa ou na especificação correspondente, e não no arquivo CLAUDE.md. Adicionar instruções temporárias a um arquivo que abrange todo o projeto torna mais difícil distingui-las das convenções que devem ser aplicadas em todo o repositório.

Por exemplo, mantenha o comando de teste do projeto no arquivo CLAUDE.md, coloque convenções específicas de componentes em uma regra com escopo de caminho e salve um procedimento de revisão recorrente como uma habilidade. Revise esses arquivos quando os comandos ou convenções forem alterados, da mesma forma que você faria com qualquer outra documentação do projeto.

As instruções, o arquivo CLAUDE.md e o guia de habilidades orientam o comportamento do Claude; eles não garantem que uma instrução será seguida. Os hooks podem executar verificações em eventos configurados, mas sua confiabilidade depende do tipo de hook e da implementação.

Um gancho de comando executa um script. Um prompt ou gancho de agente depende do julgamento de um modelo. Conforme explica o guia de melhores práticas da Anthropic: “Um prompt ou gancho de agente solicita que outro modelo decida, portanto, também não é determinístico.” Para uma regra que deva ser aplicada, use controles de permissão adequados e teste o comando ou gancho HTTP relevante, incluindo como ele lida com falhas.

Subagentes personalizados são outra forma de organizar tarefas recorrentes. Defina um especialista em `claude/agents/` quando for necessária uma função de revisão específica ou um escopo de ferramenta distinto, em vez de adicionar todas as instruções do especialista à sessão principal. Esses guias sobre o melhor modelo do Claude para o trabalho e os tipos de agentes de IA fornecem contexto adicional.

Se sua equipe mantém prompts em vários produtos de IA, confira estas ferramentas de engenharia de prompts para gerenciar bibliotecas além do Claude Code.

Quando uma sessão produz um resultado incompleto ou inadequado, verifique se a solicitação deixou decisões importantes sem solução. Esses cinco erros podem tornar o trabalho mais difícil de diagnosticar e revisar.

“Investigue o repositório” dá ao Claude poucas orientações sobre quais arquivos são importantes ou quando parar. Você pode receber um resumo genérico sem uma resposta para o problema que motivou a solicitação.

Nomeie o comportamento ou a decisão que você precisa entender, identifique um ponto de partida e defina o resultado esperado. Por exemplo: “Rastreie como esse endpoint verifica as permissões e cite as funções relevantes.” Se você usar subagentes, atribua a cada um deles uma pergunta delimitada, em vez de delegar a mesma busca irrestrita.

Alternar entre um recurso, um bug não relacionado e uma solicitação de documentação faz com que a conversa mantenha um contexto que pode não se aplicar à tarefa atual. Referências como “aquele arquivo” ou “a abordagem anterior” tornam-se ambíguas.

Use sessões separadas para trabalhos não relacionados. Se várias sessões forem editar o repositório, use árvores de trabalho do Git separadas para que elas não modifiquem o mesmo diretório de trabalho. A propósito, o comando /btw do Claude Code mantém a troca de mensagens fora do histórico principal da conversa.

Uma compilação pode ser aprovada mesmo que um recurso não funcione corretamente. Um conjunto de testes pode ser aprovado porque nunca testou a entrada que causaria falha. Pedir ao Claude para “executar os testes” não determina qual requisito esses testes verificam.

Mapeie os critérios de aceitação para verificações específicas. Para a correção de um bug, solicite evidências de que o teste de reprodução falhou antes da alteração e foi aprovado depois. Mantenha os critérios não testados visíveis, em vez de considerar um comando bem-sucedido como verificação de toda a alteração.

Um arquivo CLAUDE.md em constante expansão pode conter comandos desatualizados, regras duplicadas e instruções que contradizem os requisitos específicos da tarefa. Adicionar uma redação mais enfática não resolve esses conflitos.

Revise o arquivo em relação ao repositório atual. Remova orientações obsoletas, esclareça regras conflitantes e transfira instruções de aplicação restrita para regras ou habilidades com escopo de caminho. Se um requisito precisar ser aplicado, configure e teste os controles apropriados, em vez de depender de lembretes repetidos.

Uma revisão pode identificar, ao mesmo tempo, defeitos reais, questões duvidosas e sugestões opcionais de refatoração. Aplicar todas as sugestões pode ampliar a alteração sem melhorar o comportamento solicitado.

Solicite as evidências e o impacto por trás de cada constatação. Priorize problemas de correção e requisitos não atendidos, investigue alegações duvidosas e mantenha melhorias não relacionadas fora da comparação atual. Um revisor deve ser capaz de relatar que não há constatações passíveis de ação quando as evidências apoiarem essa conclusão.

Para adaptar um modelo, substitua seus espaços reservados pelos detalhes do seu projeto e decida o que o Claude deve fazer antes de fazer as alterações. Siga estas etapas para preparar a solicitação e revisar o resultado.

Para uma alteração pequena e bem definida, você pode pedir ao Claude para implementá-la diretamente. Para códigos desconhecidos, alterações em vários arquivos ou requisitos não resolvidos, comece com um plano.

Pressione Shift+Tab até que o modo Plan apareça ou inicie o Claude Code com o comando claude --permission-mode plan. Nesse modo, o Claude pode inspecionar arquivos e executar comandos somente de leitura sem editar seu código-fonte. Analise os arquivos, dependências e testes propostos antes de aprovar a implementação. Pressione Ctrl+G para abrir o plano proposto no seu editor.

Forneça ao Claude as evidências necessárias para compreender a tarefa: uma referência de arquivo, um log de erros limpo, uma captura de tela ou um documento de requisitos. Use @ seguido do caminho do arquivo para incluir o conteúdo desse arquivo.

Escolha o menor conjunto útil de fontes. Incluir um log ou diretório inteiro pode adicionar material irrelevante e consumir contexto. Remova credenciais e dados confidenciais antes de compartilhar logs e verifique se o Claude possui as ferramentas necessárias para acessar quaisquer URLs de documentação que você fornecer.

Por exemplo, o comando `cat error.log | claude -p "Explique este erro"` envia um log por meio de uma solicitação não interativa. Use-o somente após verificar o conteúdo do arquivo. Esse é o valor prático da IA contextual: fornecer ao modelo informações relevantes para a tarefa.

Ao adicionar um recurso, identifique um componente ou função semelhante no repositório. Indique ao Claude quais convenções devem ser seguidas, como o cliente da API, a lógica de validação, o tratamento de erros ou a estrutura de testes.

“Veja como @src/widgets/Weather.tsx busca e armazena dados em cache” fornece ao Claude uma referência concreta. Indique também quaisquer diferenças exigidas pelo novo recurso, para que ele não copie comportamentos que não sejam mais adequados. Essas convenções devem refletir o fluxo de trabalho de desenvolvimento de software da sua equipe.

Para alterações no código, especifique o comando relevante de teste, compilação ou lint e o comportamento que ele deve verificar. Para pesquisas, solicite referências de arquivos ou IDs de commit. Para trabalhos na interface do usuário, forneça uma imagem de referência e uma forma configurada de capturar a implementação na mesma janela de visualização.

Peça ao Claude para relatar o que ele realmente verificou, incluindo falhas e verificações ignoradas. Verifique se as evidências atendem aos requisitos; uma compilação aprovada não garante que todos os comportamentos solicitados funcionem.

Para tarefas mais longas, o Claude Code também oferece uma condição /goal e ganchos de parada (Stop hooks). O avaliador de metas analisa as evidências que surgem na conversa, em vez de inspecionar arquivos ou executar testes de forma independente. Um gancho de parada configurado pode bloquear a conclusão, mas há limites para bloqueios repetidos. Nenhum dos dois substitui testes adequados e a revisão humana.

Se as correções repetidas não estiverem resolvendo um problema, pare e identifique o que ficou pouco claro na solicitação original. Salve as descobertas úteis, o status atual do Git e o trabalho restante antes de limpar a conversa.

O guia de melhores práticas da Anthropic recomenda recomeçar do zero após duas correções malsucedidas na mesma questão. Use /clear e, em seguida, forneça um prompt revisado que inclua o que você aprendeu. Limpar a conversa não desfaz as alterações nos arquivos.

Pressione Esc para interromper uma resposta em execução. Com o campo de comando vazio, pressione Esc duas vezes para abrir o menu de retrocesso e escolher o que restaurar. O retrocesso não desfaz todos os efeitos externos; portanto, use checkpoints do Git e procedimentos de recuperação separados para alterações em bancos de dados ou serviços remotos.

Salve orientações para todo o projeto no arquivo CLAUDE.md, procedimentos repetíveis nas habilidades e instruções para arquivos específicos em regras com escopo de caminho. Use ganchos para ações vinculadas a eventos específicos, como executar um formatador após uma edição.

Escolha com base no momento em que a instrução deve ser aplicada:

Um requisito para um recurso geralmente deve constar na instrução da tarefa ou na especificação correspondente, e não no arquivo CLAUDE.md. Adicionar instruções temporárias a um arquivo válido para todo o projeto torna mais difícil distingui-las das convenções que devem ser aplicadas em todo o repositório.

Por exemplo, mantenha o comando de teste do projeto no arquivo CLAUDE.md, coloque convenções específicas de componentes em uma regra com escopo de caminho e salve um procedimento de revisão recorrente como uma habilidade. Revise esses arquivos quando os comandos ou convenções forem alterados, da mesma forma que você faria com qualquer outra documentação do projeto.

As instruções, o arquivo CLAUDE.md e o guia de habilidades orientam o comportamento do Claude; eles não garantem que uma instrução será seguida. Os hooks podem executar verificações em eventos configurados, mas sua confiabilidade depende do tipo de hook e da implementação.

Um gancho de comando executa um script. Um prompt ou gancho de agente depende do julgamento de um modelo. Conforme explica o guia de melhores práticas da Anthropic: “Um prompt ou gancho de agente solicita que outro modelo decida, portanto, também não é determinístico.” Para uma regra que deva ser aplicada, use controles de permissão adequados e teste o comando ou gancho HTTP relevante, incluindo como ele lida com falhas.

Subagentes personalizados são outra forma de organizar tarefas recorrentes. Defina um especialista em `claude/agents/` quando for necessária uma função de revisão específica ou um escopo de ferramenta distinto, em vez de adicionar todas as instruções do especialista à sessão principal. Esses guias sobre o melhor modelo do Claude para o trabalho e os tipos de agentes de IA fornecem contexto adicional.

Se sua equipe mantém prompts em vários produtos de IA, confira estas ferramentas de engenharia de prompts para gerenciar bibliotecas além do Claude Code.

Quando uma sessão produz um resultado incompleto ou inadequado, verifique se a solicitação deixou decisões importantes sem solução. Esses cinco erros podem tornar o trabalho mais difícil de diagnosticar e revisar.

“Investigue o repositório” dá ao Claude poucas orientações sobre quais arquivos são importantes ou quando parar. Você pode receber um resumo genérico sem uma resposta para o problema que motivou a solicitação.

Nomeie o comportamento ou a decisão que você precisa entender, identifique um ponto de partida e defina o resultado esperado. Por exemplo: “Rastreie como esse endpoint verifica as permissões e cite as funções relevantes.” Se você usar subagentes, atribua a cada um deles uma pergunta delimitada, em vez de delegar a mesma busca irrestrita.

Alternar entre um recurso, um bug não relacionado e uma solicitação de documentação faz com que a conversa mantenha um contexto que pode não se aplicar à tarefa atual. Referências como “aquele arquivo” ou “a abordagem anterior” tornam-se ambíguas.

Use sessões separadas para trabalhos não relacionados. Se várias sessões forem editar o repositório, use árvores de trabalho do Git separadas para que elas não modifiquem o mesmo diretório de trabalho. A propósito, o comando /btw do Claude Code mantém a troca de mensagens fora do histórico principal da conversa.

Uma compilação pode ser aprovada mesmo que um recurso não funcione corretamente. Um conjunto de testes pode ser aprovado porque nunca testou a entrada que causaria falha. Pedir ao Claude para “executar os testes” não determina qual requisito esses testes verificam.

Mapeie os critérios de aceitação para verificações específicas. Para a correção de um bug, solicite evidências de que o teste de reprodução falhou antes da alteração e foi aprovado depois. Mantenha os critérios não testados visíveis, em vez de tratar um comando bem-sucedido como verificação de toda a alteração.

Um arquivo CLAUDE.md em constante expansão pode conter comandos desatualizados, regras duplicadas e instruções que contradizem os requisitos específicos da tarefa. Adicionar uma redação mais enfática não resolve esses conflitos.

Revise o arquivo em relação ao repositório atual. Remova orientações obsoletas, esclareça regras conflitantes e transfira instruções de aplicação restrita para regras ou habilidades com escopo de caminho. Se um requisito precisar ser aplicado, configure e teste os controles apropriados, em vez de depender de lembretes repetidos.

Uma revisão pode identificar, ao mesmo tempo, defeitos reais, questões duvidosas e sugestões opcionais de refatoração. Aplicar todas as sugestões pode ampliar a alteração sem melhorar o comportamento solicitado.

Solicite as evidências e o impacto por trás de cada constatação. Priorize problemas de correção e requisitos não atendidos, investigue alegações duvidosas e mantenha melhorias não relacionadas fora da comparação atual. Um revisor deve ser capaz de relatar que não há constatações passíveis de ação quando as evidências apoiarem essa conclusão.

Para adaptar um modelo, substitua seus espaços reservados pelos detalhes do seu projeto e decida o que o Claude deve fazer antes de fazer as alterações. Siga estas etapas para preparar a solicitação e revisar o resultado.

Para uma alteração pequena e bem definida, você pode pedir ao Claude para implementá-la diretamente. Para códigos desconhecidos, alterações em vários arquivos ou requisitos não resolvidos, comece com um plano.

Pressione Shift+Tab até que o modo Plan apareça ou inicie o Claude Code com o comando claude --permission-mode plan. Nesse modo, o Claude pode inspecionar arquivos e executar comandos somente de leitura sem editar seu código-fonte. Analise os arquivos, dependências e testes propostos antes de aprovar a implementação. Pressione Ctrl+G para abrir o plano proposto em seu editor.

Forneça ao Claude as evidências necessárias para compreender a tarefa: uma referência de arquivo, um log de erros limpo, uma captura de tela ou um documento de requisitos. Use @ seguido do caminho do arquivo para incluir o conteúdo desse arquivo.

Escolha o menor conjunto útil de fontes. Incluir um log ou diretório inteiro pode adicionar material irrelevante e consumir contexto. Remova credenciais e dados confidenciais antes de compartilhar logs e verifique se o Claude possui as ferramentas necessárias para acessar quaisquer URLs de documentação que você fornecer.

Por exemplo, o comando `cat error.log | claude -p "Explique este erro"` envia um log por meio de uma solicitação não interativa. Use-o somente após verificar o conteúdo do arquivo. Esse é o valor prático da IA contextual: fornecer ao modelo informações relevantes para a tarefa.

Ao adicionar um recurso, identifique um componente ou função semelhante no repositório. Indique ao Claude quais convenções devem ser seguidas, como o cliente da API, a lógica de validação, o tratamento de erros ou a estrutura de testes.

“Veja como @src/widgets/Weather.tsx busca e armazena dados em cache” fornece ao Claude uma referência concreta. Indique também quaisquer diferenças exigidas pelo novo recurso, para que ele não copie comportamentos que não sejam mais adequados. Essas convenções devem refletir o fluxo de trabalho de desenvolvimento de software da sua equipe.

Para alterações no código, especifique o comando relevante de teste, compilação ou lint e o comportamento que ele deve verificar. Para pesquisas, solicite referências de arquivos ou IDs de commit. Para trabalhos na interface do usuário, forneça uma imagem de referência e uma forma configurada de capturar a implementação na mesma janela de visualização.

Peça ao Claude para relatar o que ele realmente verificou, incluindo falhas e verificações ignoradas. Verifique se as evidências atendem aos requisitos; uma compilação aprovada não garante que todos os comportamentos solicitados funcionem.

Para tarefas mais longas, o Claude Code também oferece uma condição /goal e ganchos de parada (Stop hooks). O avaliador de metas analisa as evidências que surgem na conversa, em vez de inspecionar arquivos ou executar testes de forma independente. Um gancho de parada configurado pode bloquear a conclusão, mas há limites para bloqueios repetidos. Nenhum dos dois substitui testes adequados e a revisão humana.

Se as correções repetidas não estiverem resolvendo um problema, pare e identifique o que ficou pouco claro na solicitação original. Salve as descobertas úteis, o status atual do Git e o trabalho restante antes de limpar a conversa.

O guia de melhores práticas da Anthropic recomenda recomeçar do zero após duas correções malsucedidas na mesma questão. Use /clear e, em seguida, forneça um prompt revisado que inclua o que você aprendeu. Limpar a conversa não desfaz as alterações nos arquivos.

Pressione Esc para interromper uma resposta em execução. Com o campo de comando vazio, pressione Esc duas vezes para abrir o menu de retrocesso e escolher o que restaurar. O retrocesso não desfaz todos os efeitos externos; portanto, use checkpoints do Git e procedimentos de recuperação separados para alterações em bancos de dados ou serviços remotos.

Salve orientações para todo o projeto no arquivo CLAUDE.md, procedimentos repetíveis nas habilidades e instruções para arquivos específicos em regras com escopo de caminho. Use ganchos para ações vinculadas a eventos específicos, como executar um formatador após uma edição.

Escolha com base no momento em que a instrução deve ser aplicada:

Um requisito para um recurso geralmente deve constar na instrução da tarefa ou na especificação correspondente, e não no arquivo CLAUDE.md. Adicionar instruções temporárias a um arquivo válido para todo o projeto torna mais difícil distingui-las das convenções que devem ser aplicadas em todo o repositório.

Por exemplo, mantenha o comando de teste do projeto no arquivo CLAUDE.md, coloque convenções específicas de componentes em uma regra com escopo de caminho e salve um procedimento de revisão recorrente como uma habilidade. Revise esses arquivos quando os comandos ou convenções forem alterados, da mesma forma que você faria com qualquer outra documentação do projeto.

As instruções, o arquivo CLAUDE.md e o guia de habilidades orientam o comportamento do Claude; eles não garantem que uma instrução será seguida. Os hooks podem executar verificações em eventos configurados, mas sua confiabilidade depende do tipo de hook e da implementação.

Um gancho de comando executa um script. Um prompt ou gancho de agente depende do julgamento de um modelo. Conforme explica o guia de melhores práticas da Anthropic: “Um prompt ou gancho de agente solicita que outro modelo decida, portanto, também não é determinístico.” Para uma regra que deva ser aplicada, use controles de permissão adequados e teste o comando ou gancho HTTP relevante, incluindo como ele lida com falhas.

Subagentes personalizados são outra forma de organizar tarefas recorrentes. Defina um especialista em `claude/agents/` quando for necessária uma função de revisão específica ou um escopo de ferramenta distinto, em vez de adicionar todas as instruções do especialista à sessão principal. Esses guias sobre o melhor modelo do Claude para o trabalho e os tipos de agentes de IA fornecem contexto adicional.

Se sua equipe mantém prompts em vários produtos de IA, confira estas ferramentas de engenharia de prompts para gerenciar bibliotecas além do Claude Code.

Quando uma sessão produz um resultado incompleto ou inadequado, verifique se a solicitação deixou decisões importantes sem solução. Esses cinco erros podem tornar o trabalho mais difícil de diagnosticar e revisar.

“Investigue o repositório” dá ao Claude poucas orientações sobre quais arquivos são importantes ou quando parar. Você pode receber um resumo genérico sem uma resposta para o problema que motivou a solicitação.

Nomeie o comportamento ou a decisão que você precisa entender, identifique um ponto de partida e defina o resultado esperado. Por exemplo: “Rastreie como esse endpoint verifica as permissões e cite as funções relevantes.” Se você usar subagentes, atribua a cada um deles uma pergunta delimitada, em vez de delegar a mesma busca irrestrita.

Alternar entre um recurso, um bug não relacionado e uma solicitação de documentação faz com que a conversa mantenha um contexto que pode não se aplicar à tarefa atual. Referências como “aquele arquivo” ou “a abordagem anterior” tornam-se ambíguas.

Use sessões separadas para trabalhos não relacionados. Se várias sessões forem editar o repositório, use árvores de trabalho do Git separadas para que elas não modifiquem o mesmo diretório de trabalho. A propósito, o comando /btw do Claude Code mantém a troca de mensagens fora do histórico principal da conversa.

Uma compilação pode ser aprovada mesmo que um recurso não funcione corretamente. Um conjunto de testes pode ser aprovado porque nunca testou a entrada que causaria falha. Pedir ao Claude para “executar os testes” não determina qual requisito esses testes verificam.

Mapeie os critérios de aceitação para verificações específicas. Para a correção de um bug, solicite comprovação de que o teste de reprodução falhou antes da alteração e foi aprovado depois. Mantenha os critérios não testados visíveis, em vez de considerar um comando bem-sucedido como verificação de toda a alteração.

Um arquivo CLAUDE.md em constante expansão pode conter comandos desatualizados, regras duplicadas e instruções que contradizem os requisitos específicos da tarefa. Adicionar uma redação mais enfática não resolve esses conflitos.

Revise o arquivo em relação ao repositório atual. Remova orientações obsoletas, esclareça regras conflitantes e transfira instruções de aplicação restrita para regras ou habilidades com escopo de caminho. Se um requisito precisar ser aplicado, configure e teste os controles apropriados, em vez de depender de lembretes repetidos.

Uma revisão pode identificar, ao mesmo tempo, defeitos reais, questões duvidosas e sugestões opcionais de refatoração. Aplicar todas as sugestões pode ampliar a alteração sem melhorar o comportamento solicitado.

Solicite as evidências e o impacto por trás de cada constatação. Priorize problemas de correção e requisitos não atendidos, investigue alegações duvidosas e mantenha melhorias não relacionadas fora da comparação atual. Um revisor deve ser capaz de relatar que não há constatações passíveis de ação quando as evidências apoiarem essa conclusão.

Para adaptar um modelo, substitua seus espaços reservados pelos detalhes do seu projeto e decida o que o Claude deve fazer antes de fazer as alterações. Siga estas etapas para preparar a solicitação e revisar o resultado.

Para uma alteração pequena e bem definida, você pode pedir ao Claude para implementá-la diretamente. Para códigos desconhecidos, alterações em vários arquivos ou requisitos não resolvidos, comece com um plano.

Pressione Shift+Tab até que o modo Plan apareça ou inicie o Claude Code com o comando claude --permission-mode plan. Nesse modo, o Claude pode inspecionar arquivos e executar comandos somente de leitura sem editar seu código-fonte. Analise os arquivos, dependências e testes propostos antes de aprovar a implementação. Pressione Ctrl+G para abrir o plano proposto em seu editor.

Forneça ao Claude as evidências necessárias para compreender a tarefa: uma referência de arquivo, um log de erros limpo, uma captura de tela ou um documento de requisitos. Use @ seguido do caminho do arquivo para incluir o conteúdo desse arquivo.

Escolha o menor conjunto útil de fontes. Incluir um log ou diretório inteiro pode adicionar material irrelevante e consumir contexto. Remova credenciais e dados confidenciais antes de compartilhar logs e verifique se o Claude possui as ferramentas necessárias para acessar quaisquer URLs de documentação que você fornecer.

Por exemplo, o comando `cat error.log | claude -p "Explique este erro"` envia um log por meio de uma solicitação não interativa. Use-o somente após verificar o conteúdo do arquivo. Esse é o valor prático da IA contextual: fornecer ao modelo informações relevantes para a tarefa.

Ao adicionar um recurso, identifique um componente ou função semelhante no repositório. Indique ao Claude quais convenções devem ser seguidas, como o cliente da API, a lógica de validação, o tratamento de erros ou a estrutura de testes.

“Veja como @src/widgets/Weather.tsx busca e armazena dados em cache” fornece ao Claude uma referência concreta. Indique também quaisquer diferenças exigidas pelo novo recurso, para que ele não copie comportamentos que não sejam mais adequados. Essas convenções devem refletir o fluxo de trabalho de desenvolvimento de software da sua equipe.

Para alterações no código, especifique o comando relevante de teste, compilação ou lint e o comportamento que ele deve verificar. Para pesquisas, solicite referências de arquivos ou IDs de commit. Para trabalhos na interface do usuário, forneça uma imagem de referência e uma forma configurada de capturar a implementação na mesma janela de visualização.

Peça ao Claude para relatar o que ele realmente verificou, incluindo falhas e verificações ignoradas. Verifique se as evidências atendem aos requisitos; uma compilação bem-sucedida não garante que todos os comportamentos solicitados funcionem.

Para tarefas mais longas, o Claude Code também oferece uma condição /goal e ganchos de parada (Stop hooks). O avaliador de metas analisa as evidências que surgem na conversa, em vez de inspecionar arquivos ou executar testes de forma independente. Um gancho de parada configurado pode bloquear a conclusão, mas há limites para bloqueios repetidos. Nenhum dos dois substitui testes adequados e a revisão humana.

Se as correções repetidas não estiverem resolvendo um problema, pare e identifique o que ficou pouco claro na solicitação original. Salve as descobertas úteis, o status atual do Git e o trabalho restante antes de limpar a conversa.

O guia de melhores práticas da Anthropic recomenda recomeçar do zero após duas correções malsucedidas na mesma questão. Use /clear e, em seguida, forneça um prompt revisado que inclua o que você aprendeu. Limpar a conversa não desfaz as alterações nos arquivos.

Pressione Esc para interromper uma resposta em execução. Com o campo de comando vazio, pressione Esc duas vezes para abrir o menu de retrocesso e escolher o que restaurar. O retrocesso não desfaz todos os efeitos externos; portanto, use checkpoints do Git e procedimentos de recuperação separados para alterações em bancos de dados ou serviços remotos.

Salve orientações para todo o projeto no arquivo CLAUDE.md, procedimentos repetíveis nas habilidades e instruções para arquivos específicos em regras com escopo de caminho. Use ganchos para ações vinculadas a eventos específicos, como executar um formatador após uma edição.

Escolha com base no momento em que a instrução deve ser aplicada:

Um requisito para um recurso geralmente deve constar na instrução da tarefa ou na especificação correspondente, e não no arquivo CLAUDE.md. Adicionar instruções temporárias a um arquivo que abrange todo o projeto torna mais difícil distingui-las das convenções que devem ser aplicadas em todo o repositório.

Por exemplo, mantenha o comando de teste do projeto no arquivo CLAUDE.md, coloque convenções específicas de componentes em uma regra com escopo de caminho e salve um procedimento de revisão recorrente como uma habilidade. Revise esses arquivos quando os comandos ou convenções forem alterados, da mesma forma que você faria com qualquer outra documentação do projeto.

As instruções, o arquivo CLAUDE.md e o guia de habilidades orientam o comportamento do Claude; eles não garantem que uma instrução será seguida. Os hooks podem executar verificações em eventos configurados, mas sua confiabilidade depende do tipo de hook e da implementação.

Um gancho de comando executa um script. Um prompt ou gancho de agente depende do julgamento de um modelo. Conforme explica o guia de melhores práticas da Anthropic: “Um prompt ou gancho de agente solicita que outro modelo decida, portanto, também não é determinístico.” Para uma regra que deva ser aplicada, use controles de permissão adequados e teste o comando ou gancho HTTP relevante, incluindo como ele lida com falhas.

Subagentes personalizados são outra forma de organizar tarefas recorrentes. Defina um especialista em `claude/agents/` quando for necessária uma função de revisão específica ou um escopo de ferramenta distinto, em vez de adicionar todas as instruções do especialista à sessão principal. Esses guias sobre o melhor modelo do Claude para o trabalho e os tipos de agentes de IA fornecem contexto adicional.

Se sua equipe mantém prompts em vários produtos de IA, confira estas ferramentas de engenharia de prompts para gerenciar bibliotecas além do Claude Code.

Quando uma sessão produz um resultado incompleto ou inadequado, verifique se a solicitação deixou decisões importantes sem solução. Esses cinco erros podem tornar o trabalho mais difícil de diagnosticar e revisar.

“Investigue o repositório” dá ao Claude poucas orientações sobre quais arquivos são importantes ou quando parar. Você pode receber um resumo genérico sem uma resposta para o problema que motivou a solicitação.

Nomeie o comportamento ou a decisão que você precisa entender, identifique um ponto de partida e defina o resultado esperado. Por exemplo: “Rastreie como esse endpoint verifica as permissões e cite as funções relevantes.” Se você usar subagentes, atribua a cada um deles uma pergunta delimitada, em vez de delegar a mesma busca irrestrita.

Alternar entre um recurso, um bug não relacionado e uma solicitação de documentação faz com que a conversa mantenha um contexto que pode não se aplicar à tarefa atual. Referências como “aquele arquivo” ou “a abordagem anterior” tornam-se ambíguas.

Use sessões separadas para trabalhos não relacionados. Se várias sessões forem editar o repositório, use árvores de trabalho do Git separadas para que elas não modifiquem o mesmo diretório de trabalho. A propósito, o comando /btw do Claude Code mantém a troca de mensagens fora do histórico principal da conversa.

Uma compilação pode ser aprovada mesmo que um recurso não funcione corretamente. Um conjunto de testes pode ser aprovado porque nunca testou a entrada que causaria falha. Pedir ao Claude para “executar os testes” não determina qual requisito esses testes verificam.

Mapeie os critérios de aceitação para verificações específicas. Para a correção de um bug, solicite evidências de que o teste de reprodução falhou antes da alteração e foi aprovado depois. Mantenha os critérios não testados visíveis, em vez de tratar um comando bem-sucedido como verificação de toda a alteração.

Um arquivo CLAUDE.md em constante expansão pode conter comandos desatualizados, regras duplicadas e instruções que contradizem os requisitos específicos da tarefa. Adicionar uma redação mais enfática não resolve esses conflitos.

Revise o arquivo em relação ao repositório atual. Remova orientações obsoletas, esclareça regras conflitantes e transfira instruções de aplicação restrita para regras ou habilidades com escopo de caminho. Se um requisito precisar ser aplicado, configure e teste os controles apropriados, em vez de depender de lembretes repetidos.

Uma revisão pode identificar, ao mesmo tempo, defeitos reais, questões duvidosas e sugestões opcionais de refatoração. Aplicar todas as sugestões pode ampliar a alteração sem melhorar o comportamento solicitado.

Solicite as evidências e o impacto por trás de cada constatação. Priorize problemas de correção e requisitos não atendidos, investigue alegações duvidosas e mantenha melhorias não relacionadas fora da comparação atual. Um revisor deve ser capaz de relatar que não há constatações passíveis de ação quando as evidências apoiarem essa conclusão.

Para adaptar um modelo, substitua seus espaços reservados pelos detalhes do seu projeto e decida o que o Claude deve fazer antes de fazer as alterações. Siga estas etapas para preparar a solicitação e revisar o resultado.

Para uma alteração pequena e bem definida, você pode pedir ao Claude para implementá-la diretamente. Para códigos desconhecidos, alterações em vários arquivos ou requisitos não resolvidos, comece com um plano.

Pressione Shift+Tab até que o modo Plan apareça ou inicie o Claude Code com o comando claude --permission-mode plan. Nesse modo, o Claude pode inspecionar arquivos e executar comandos somente de leitura sem editar seu código-fonte. Analise os arquivos, dependências e testes propostos antes de aprovar a implementação. Pressione Ctrl+G para abrir o plano proposto em seu editor.

Forneça ao Claude as evidências necessárias para compreender a tarefa: uma referência de arquivo, um log de erros limpo, uma captura de tela ou um documento de requisitos. Use @ seguido do caminho do arquivo para incluir o conteúdo desse arquivo.

Escolha o menor conjunto útil de fontes. Incluir um log ou diretório inteiro pode adicionar material irrelevante e consumir contexto. Remova credenciais e dados confidenciais antes de compartilhar logs e verifique se o Claude possui as ferramentas necessárias para acessar quaisquer URLs de documentação que você fornecer.

Por exemplo, o comando `cat error.log | claude -p "Explique este erro"` envia um log por meio de uma solicitação não interativa. Use-o somente após verificar o conteúdo do arquivo. Esse é o valor prático da IA contextual: fornecer ao modelo informações relevantes para a tarefa.

Ao adicionar um recurso, identifique um componente ou função semelhante no repositório. Indique ao Claude quais convenções devem ser seguidas, como o cliente da API, a lógica de validação, o tratamento de erros ou a estrutura de testes.

“Veja como @src/widgets/Weather.tsx busca e armazena dados em cache” fornece ao Claude uma referência concreta. Indique também quaisquer diferenças exigidas pelo novo recurso, para que ele não copie comportamentos que não sejam mais adequados. Essas convenções devem refletir o fluxo de trabalho de desenvolvimento de software da sua equipe.

Para alterações no código, especifique o comando relevante de teste, compilação ou lint e o comportamento que ele deve verificar. Para pesquisas, solicite referências de arquivos ou IDs de commit. Para trabalhos na interface do usuário, forneça uma imagem de referência e uma forma configurada de capturar a implementação na mesma janela de visualização.

Peça ao Claude para relatar o que ele realmente verificou, incluindo falhas e verificações ignoradas. Verifique se as evidências atendem aos requisitos; uma compilação bem-sucedida não garante que todos os comportamentos solicitados estejam funcionando.

Para tarefas mais longas, o Claude Code também oferece uma condição /goal e ganchos de parada (Stop hooks). O avaliador de metas analisa as evidências que surgem na conversa, em vez de inspecionar arquivos ou executar testes de forma independente. Um gancho de parada configurado pode bloquear a conclusão, mas há limites para bloqueios repetidos. Nenhum dos dois substitui testes adequados e a revisão humana.

Se as correções repetidas não estiverem resolvendo um problema, pare e identifique o que ficou pouco claro na solicitação original. Salve as descobertas úteis, o status atual do Git e o trabalho restante antes de limpar a conversa.

O guia de melhores práticas da Anthropic recomenda recomeçar do zero após duas correções malsucedidas na mesma questão. Use /clear e, em seguida, forneça um prompt revisado que inclua o que você aprendeu. Limpar a conversa não desfaz as alterações nos arquivos.

Pressione Esc para interromper uma resposta em execução. Com o campo de comando vazio, pressione Esc duas vezes para abrir o menu de retrocesso e escolher o que restaurar. O retrocesso não desfaz todos os efeitos externos; portanto, use checkpoints do Git e procedimentos de recuperação separados para alterações em bancos de dados ou serviços remotos.

Salve orientações para todo o projeto no arquivo CLAUDE.md, procedimentos repetíveis nas habilidades e instruções para arquivos específicos em regras com escopo de caminho. Use ganchos para ações vinculadas a eventos específicos, como executar um formatador após uma edição.

Escolha com base no momento em que a instrução deve ser aplicada:

Um requisito para um recurso geralmente deve constar na instrução da tarefa ou na especificação correspondente, e não no arquivo CLAUDE.md. Adicionar instruções temporárias a um arquivo que abrange todo o projeto torna mais difícil distingui-las das convenções que devem ser aplicadas em todo o repositório.

Por exemplo, mantenha o comando de teste do projeto no arquivo CLAUDE.md, coloque convenções específicas de componentes em uma regra com escopo de caminho e salve um procedimento de revisão recorrente como uma habilidade. Revise esses arquivos quando os comandos ou convenções forem alterados, da mesma forma que você faria com qualquer outra documentação do projeto.

As instruções, o arquivo CLAUDE.md e o guia de habilidades orientam o comportamento do Claude; eles não garantem que uma instrução será seguida. Os hooks podem executar verificações em eventos configurados, mas sua confiabilidade depende do tipo de hook e da implementação.

Um gancho de comando executa um script. Um prompt ou gancho de agente depende do julgamento de um modelo. Conforme explica o guia de melhores práticas da Anthropic: “Um prompt ou gancho de agente solicita que outro modelo decida, portanto, também não é determinístico.” Para uma regra que deva ser aplicada, use controles de permissão adequados e teste o comando ou gancho HTTP relevante, incluindo como ele lida com falhas.

Subagentes personalizados são outra forma de organizar tarefas recorrentes. Defina um especialista em `claude/agents/` quando for necessária uma função de revisão específica ou um escopo de ferramenta distinto, em vez de adicionar todas as instruções do especialista à sessão principal. Esses guias sobre o melhor modelo do Claude para o trabalho e os tipos de agentes de IA fornecem contexto adicional.

Se sua equipe mantém prompts em vários produtos de IA, confira estas ferramentas de engenharia de prompts para gerenciar bibliotecas além do Claude Code.

Quando uma sessão produz um resultado incompleto ou inadequado, verifique se a solicitação deixou decisões importantes sem solução. Esses cinco erros podem tornar o trabalho mais difícil de diagnosticar e revisar.

“Investigue o repositório” dá ao Claude poucas orientações sobre quais arquivos são importantes ou quando parar. Você pode receber um resumo genérico sem uma resposta para o problema que motivou a solicitação.

Nomeie o comportamento ou a decisão que você precisa entender, identifique um ponto de partida e defina o resultado esperado. Por exemplo: “Rastreie como esse endpoint verifica as permissões e cite as funções relevantes.” Se você usar subagentes, atribua a cada um deles uma pergunta delimitada, em vez de delegar a mesma busca irrestrita.

Alternar entre um recurso, um bug não relacionado e uma solicitação de documentação faz com que a conversa mantenha um contexto que pode não se aplicar à tarefa atual. Referências como “aquele arquivo” ou “a abordagem anterior” tornam-se ambíguas.

Use sessões separadas para trabalhos não relacionados. Se várias sessões forem editar o repositório, use árvores de trabalho do Git separadas para que elas não modifiquem o mesmo diretório de trabalho. A propósito, o comando /btw do Claude Code mantém a troca de mensagens fora do histórico principal da conversa.

Uma compilação pode ser aprovada mesmo que um recurso não funcione corretamente. Um conjunto de testes pode ser aprovado porque nunca testou a entrada que causaria falha. Pedir ao Claude para “executar os testes” não determina qual requisito esses testes verificam.

Mapeie os critérios de aceitação para verificações específicas. Para a correção de um bug, solicite evidências de que o teste de reprodução falhou antes da alteração e foi aprovado depois. Mantenha os critérios não testados visíveis, em vez de considerar um comando bem-sucedido como verificação de toda a alteração.

Um arquivo CLAUDE.md em constante expansão pode conter comandos desatualizados, regras duplicadas e instruções que contradizem os requisitos específicos da tarefa. Adicionar uma redação mais enfática não resolve esses conflitos.

Revise o arquivo em relação ao repositório atual. Remova orientações obsoletas, esclareça regras conflitantes e transfira instruções de aplicação restrita para regras ou habilidades com escopo de caminho. Se um requisito precisar ser aplicado, configure e teste os controles apropriados, em vez de depender de lembretes repetidos.

Uma revisão pode identificar, ao mesmo tempo, defeitos reais, questões duvidosas e sugestões opcionais de refatoração. Aplicar todas as sugestões pode ampliar a alteração sem melhorar o comportamento solicitado.

Solicite as evidências e o impacto por trás de cada constatação. Priorize problemas de correção e requisitos não atendidos, investigue alegações duvidosas e mantenha melhorias não relacionadas fora da comparação atual. Um revisor deve ser capaz de relatar que não há constatações passíveis de ação quando as evidências apoiarem essa conclusão.