50 Dicas do Claude Code: Melhores Práticas para Usar Todo Dia

Você já usa o Claude Code há tempo suficiente para saber que ele funciona, mas talvez ainda não esteja extraindo todo o potencial da ferramenta.

Este guia reúne 50 boas práticas para usar Claude Code com mais produtividade, segurança e previsibilidade. As dicas servem tanto para quem está na primeira semana quanto para quem já usa agentes de programação diariamente em projetos reais.

A ideia central é simples: o Claude Code funciona melhor quando você não o trata apenas como um chatbot de código, mas como um agente de desenvolvimento configurável, capaz de ler sua base, executar comandos, usar ferramentas externas, revisar mudanças, trabalhar com subagentes, seguir regras do projeto e automatizar fluxos repetitivos.

Ao longo do artigo, você verá dicas sobre permissões, comandos, CLAUDE.md, hooks, MCP, Skills, worktrees, subagentes, revisão de PRs, automações e operações em lote.

1. Configure o alias cc

Uma das formas mais rápidas de iniciar uma sessão do Claude Code é criar um alias no terminal. Adicione ao seu ~/.zshrc ou ~/.bashrc:

alias cc='claude --dangerously-skip-permissions'

Depois, execute:

source ~/.zshrc

Com isso, você digita apenas cc em vez de claude. O problema é que esse alias usa uma flag perigosa, que pula prompts de permissão. O próprio nome --dangerously-skip-permissions já deixa claro: use apenas quando souber exatamente o que o Claude Code pode fazer no seu projeto.

Leia também: personalizando o Claude Code.

Dica avançada complementar

Crie dois aliases: um seguro e um perigoso. Por exemplo:

alias ccs='claude'
alias ccd='claude --dangerously-skip-permissions'

Use ccs no dia a dia e reserve ccd para worktrees descartáveis, contêineres Docker ou tarefas de baixo risco. Em projetos reais, é melhor combinar /permissions, /sandbox e hooks de bloqueio do que liberar tudo por padrão.

2. Prefixe ! para executar comandos bash diretamente

Dentro do Claude Code, você pode executar comandos bash diretamente usando !. Exemplos:

!git status
!npm test
!pnpm lint
!git diff

O comando é executado imediatamente, e a saída entra no contexto da conversa. Isso é mais rápido do que pedir: “Claude, execute git status”.

Dica avançada complementar

Use comandos diretos para gerar evidência antes de pedir uma correção. Por exemplo, execute !npm test e depois diga: “corrija apenas as falhas mostradas acima”. Isso força o Claude a trabalhar com dados reais, reduz suposições e evita mudanças desnecessárias.

3. Pressione Esc para parar o Claude. Use Esc+Esc ou /rewind para desfazer

Esc interrompe o Claude no meio de uma ação sem perder o contexto. Isso é útil quando você percebe que ele está seguindo por um caminho errado.

Esc+Esc, ou /rewind, permite voltar para checkpoints anteriores. Você pode restaurar código, conversa ou ambos, dependendo do ponto de retorno.

Isso encoraja experimentação. Você pode deixar o Claude tentar uma abordagem que parece promissora, mas ainda incerta. Se não funcionar, volte ao checkpoint.

Uma ressalva importante: checkpoints ajudam com edições de arquivos, mas alterações feitas por comandos bash, migrações de banco, seeds ou operações externas podem não ser totalmente revertidas.

Dica avançada complementar

Antes de uma refatoração arriscada, faça um commit local ou crie um worktree. /rewind é ótimo para voltar conversas e edições, mas Git continua sendo a camada mais confiável de segurança quando comandos, scripts e banco de dados entram no fluxo.

4. Dê ao Claude uma forma de verificar o próprio trabalho

Não peça apenas para o Claude implementar algo. Peça também para ele verificar se a mudança funcionou.

Refatore o middleware de auth para usar JWT em vez de tokens de sessão.
Execute a suíte de testes existente após as alterações.
Corrija qualquer falha antes de considerar concluído.

Esse ciclo de feedback melhora muito a qualidade. O Claude executa testes, lê falhas, corrige o problema e tenta novamente.

Para mudanças de UI, configure o servidor MCP do Playwright. Assim, o Claude pode abrir o navegador, interagir com a página e verificar se a interface funciona.

Dica avançada complementar

Defina um critério de conclusão explícito: testes passando, lint sem erro, typecheck aprovado, comportamento validado e diff revisado. Para UI, peça também screenshots antes/depois ou validação visual via Playwright. Isso detecta problemas que testes unitários não enxergam.

5. Instale um plugin de inteligência de código para sua linguagem

Plugins LSP fornecem diagnósticos automáticos para o Claude Code. Eles ajudam o agente a identificar erros de tipo, imports não usados, símbolos inexistentes e problemas de navegação no código.

Exemplos:

/plugin install typescript-lsp@claude-plugins-official
/plugin install pyright-lsp@claude-plugins-official
/plugin install rust-analyzer-lsp@claude-plugins-official
/plugin install gopls-lsp@claude-plugins-official

Também existem plugins para C#, Java, Kotlin, Swift, PHP, Lua e C/C++. Execute /plugin e veja a aba Discover para conferir a lista disponível.

Dica avançada complementar

Em projetos TypeScript, não dependa apenas do LSP. Combine o plugin com tsc --noEmit, testes automatizados e validação de path aliases. O LSP ajuda localmente; o typecheck completo detecta problemas de configuração, tipos globais, decorators e inconsistências entre pacotes.

6. Use a CLI do gh e ensine o Claude qualquer ferramenta de linha de comando

A CLI do GitHub permite gerenciar PRs, issues, comentários e revisões sem depender de um servidor MCP separado.

Ferramentas CLI costumam ser eficientes porque não carregam esquemas de ferramentas grandes no contexto. O mesmo vale para jq, curl, docker, sentry-cli e ferramentas internas.

Você pode pedir:

Use sentry-cli --help para aprender a ferramenta.
Depois encontre o erro mais recente em produção e explique a provável causa.

Dica avançada complementar

Crie uma seção no CLAUDE.md chamada “Ferramentas CLI disponíveis”, com exemplos de uso seguro para gh, jq, curl, docker e CLIs internas. Isso evita que o Claude redescubra sintaxe a cada sessão.

7. Adicione “ultrathink” ou ajuste /effort para raciocínio complexo

Para decisões de arquitetura, debugging difícil, análise de tradeoffs e tarefas com múltiplas etapas, peça mais raciocínio antes de agir.

Você também pode usar /effort para ajustar o nível de esforço. Use níveis mais baixos para tarefas simples e níveis mais altos para problemas complexos.

Não faz sentido gastar muito raciocínio em uma renomeação de variável, mas faz sentido para revisar uma migração crítica ou redesenhar um fluxo de autenticação.

Dica avançada complementar

Combine raciocínio alto com uma trava de ação: “pense profundamente, mas não edite arquivos ainda”. Primeiro peça opções, riscos, impacto, arquivos envolvidos e estratégia de validação. Só depois autorize implementação.

8. Use Skills para conhecimento sob demanda

Skills são arquivos markdown que estendem o conhecimento do Claude sob demanda. Diferente do CLAUDE.md, que costuma carregar no início da sessão, Skills entram quando são relevantes.

Você pode criar Skills em .claude/skills/ ou instalar plugins que já trazem Skills prontas.

Use Skills para conhecimento especializado: convenções de API, procedimentos de deploy, padrões internos, revisão de PR, análise de logs ou debugging recorrente.

Dica avançada complementar

Transforme playbooks repetitivos em Skills. Se você já colou o mesmo procedimento três vezes, ele provavelmente merece uma Skill. Exemplos úteis: “revisar PR NestJS”, “diagnosticar lentidão no PostgreSQL”, “gerar release notes” e “auditar fluxo de auth”.

9. Controle o Claude Code pelo celular

Execute:

claude remote-control

Depois, conecte-se em claude.ai/code ou no aplicativo Claude para iOS/Android.

A sessão continua rodando localmente na sua máquina. O celular ou navegador funciona como uma janela remota, permitindo enviar mensagens, aprovar ferramentas e acompanhar o progresso.

Dica avançada complementar

Não combine controle remoto com permissões totais em repositórios sensíveis. Use o celular para monitorar, aprovar e revisar. Para tarefas longas sem supervisão, prefira sandbox, Docker ou worktree descartável.

10. Expanda a janela de contexto quando necessário

Janelas de contexto maiores ajudam quando você precisa analisar muitos arquivos, longas especificações ou monorepos. Porém, mais contexto não significa automaticamente melhor resposta.

Contexto grande pode melhorar cobertura, mas também pode aumentar ruído. Às vezes, apontar arquivos específicos com @arquivo gera resultado melhor do que despejar o projeto inteiro.

Dica avançada complementar

Antes de aumentar o contexto, reduza ruído: use @arquivo, /clear, subagentes de exploração e resumos focados. Contexto grande deve ser usado quando a tarefa realmente exige comparar muitas partes do sistema.

11. Use o Modo de Planejamento quando não sabe como abordar algo

Use o Modo de Planejamento para mudanças em múltiplos arquivos, código desconhecido, bugs difíceis e decisões arquiteturais.

Ele evita que o Claude implemente com confiança a solução errada.

Você pode alternar para o modo de planejamento com Shift+Tab ou usar o comando correspondente na sessão.

Dica avançada complementar

Peça que o plano contenha quatro itens: arquivos prováveis, riscos, perguntas pendentes e validações. Um bom plano reduz incerteza. Se ele apenas repetir seu pedido, peça uma revisão do plano antes de permitir implementação.

12. Execute /clear entre tarefas não relacionadas

Uma sessão limpa com um prompt preciso costuma ser melhor do que uma sessão longa e carregada de contexto antigo.

Quando a tarefa mudar, use:

/clear

Isso evita que decisões, erros e tentativas anteriores contaminem a nova tarefa.

Dica avançada complementar

Antes de limpar, peça um resumo operacional em 10 linhas: objetivo, decisões tomadas, arquivos alterados, testes executados, falhas pendentes e próximo passo. Cole esse resumo na nova sessão se precisar preservar continuidade.

13. Pare de interpretar bugs para o Claude. Cole os dados brutos.

Descrever um bug em palavras pode introduzir interpretação errada. Logs, stack traces, saídas de CI e mensagens de erro são mais úteis.

Exemplos:

cat error.log | claude "explique este erro e sugira uma correção"

npm test 2>&1 | claude "corrija os testes com falha"

O Claude consegue rastrear logs, identificar padrões e propor correções a partir dos dados reais.

Dica avançada complementar

Cole dados brutos, mas remova segredos antes. Mascare tokens, chaves de API, cookies, DSNs, e-mails, IDs sensíveis e dados de clientes. Debug bom é detalhado, mas não deve vazar credenciais.

14. Use /btw para perguntas rápidas paralelas

/btw abre um espaço para perguntas rápidas sem poluir o histórico principal da conversa.

Use para dúvidas como:

• Por que você escolheu essa abordagem?
• Qual é o tradeoff com a outra opção?
• Existe um risco oculto aqui?

Dica avançada complementar

Use /btw para esclarecimentos, não para novas instruções de implementação. Se a resposta mudar o plano principal, volte à conversa principal e peça explicitamente para incorporar a decisão.

15. Use --worktree para branches paralelas isoladas

claude --worktree feature-auth cria uma cópia de trabalho isolada com uma nova branch.

Isso permite rodar sessões paralelas do Claude Code sem que uma sobrescreva arquivos da outra.

Worktrees são úteis para testar abordagens diferentes, rodar refatorações em paralelo e isolar tarefas arriscadas.

A Builder.io usa uma abordagem parecida ao mover agentes para contêineres na nuvem com preview no navegador.

Dica avançada complementar

Padronize nomes de worktrees por intenção: wt/fix-ci, wt/refactor-auth, wt/review-payments. Ao terminar, peça ao Claude um resumo do diff, testes executados e comandos seguros para limpar o worktree.

16. Salve seu prompt com Ctrl+S

Se você estiver escrevendo um prompt longo e precisar fazer uma pergunta rápida antes, use Ctrl+S para salvar o rascunho.

Depois de enviar a pergunta rápida, o prompt salvo é restaurado automaticamente.

Dica avançada complementar

Para prompts realmente importantes, mantenha um arquivo prompt.md, PLAN.md ou SPEC.md. Assim você pode versionar, reaproveitar e melhorar instruções com base nos resultados.

17. Mande tarefas longas para segundo plano com Ctrl+B

Quando o Claude iniciar um comando demorado, como build, testes ou migração, pressione Ctrl+B para enviá-lo ao segundo plano.

O processo continua rodando, e você pode seguir conversando com o Claude enquanto aguarda o resultado.

Dica avançada complementar

Peça ao Claude para continuar revisando o diff enquanto o teste roda, mas deixe claro: “não considere concluído até analisar a saída final do comando”. Isso evita que a tarefa seja encerrada antes da validação real.

18. Adicione uma linha de status ao vivo

A statusline mostra informações úteis no terminal: diretório atual, branch Git, modelo em uso, uso de contexto e outras informações.

Configure com:

/statusline

O Claude pode gerar o script automaticamente com base no que você quer exibir.

Veja também: personalizando o Claude Code.

Dica avançada complementar

Inclua branch, diretório, modo de permissão, modelo e uso de contexto. Esses dados evitam erros comuns: editar a branch errada, continuar sessão quase sem contexto ou rodar comandos no diretório incorreto.

19. Use subagentes para manter seu contexto principal limpo

Subagentes permitem delegar investigação para outra instância do Claude, com contexto separado.

Exemplo:

Use um subagente para descobrir como o fluxo de pagamento lida com transações falhas.

O subagente analisa arquivos, entende o fluxo e retorna um resumo conciso para a sessão principal.

Veja também: subagentes e equipes de agentes.

Dica avançada complementar

Use subagentes principalmente para tarefas somente leitura: mapear fluxo, revisar segurança, localizar origem de bug ou comparar abordagens. Para escrita paralela, prefira worktrees para evitar conflitos de arquivo.

20. Use equipes de agentes para coordenação em múltiplas sessões

Equipes de agentes permitem distribuir tarefas entre vários agentes com uma coordenação central.

Esse recurso é poderoso, mas deve ser usado com cuidado. Comece com poucos agentes e tarefas bem separadas.

Evite que dois agentes editem os mesmos arquivos ao mesmo tempo.

Dica avançada complementar

Use equipes primeiro para pesquisa e revisão, não implementação paralela. Defina ownership por módulo, pasta ou worktree. Isso reduz sobrescrita, conflitos e diffs difíceis de revisar.

21. Guie a compactação com instruções

Quando o contexto compacta automaticamente ou via /compact, diga ao Claude o que preservar.

Exemplo:

/compact foque nas alterações da API, arquivos modificados, testes pendentes e restrições atuais.

Você também pode adicionar uma regra permanente ao CLAUDE.md.

Dica avançada complementar

Preserve sempre: objetivo atual, decisões tomadas, arquivos alterados, comandos executados, falhas de teste, restrições e próximos passos. Isso reduz perda de continuidade em sessões longas.

22. Use /loop para verificações recorrentes

/loop agenda um prompt recorrente enquanto a sessão permanece aberta.

Exemplo:

/loop 5m verifique se o deploy foi bem-sucedido e reporte

É útil para monitorar CI, deploys, jobs assíncronos ou serviços externos.

Dica avançada complementar

Use /loop para observação, não para ações destrutivas. Bons usos: healthcheck, deploy, CI e monitoramento. Evite loops que fazem rollback, deploy automático, truncate, delete ou alterações em produção.

23. Use ditado por voz para prompts mais ricos

Com /voice, você pode ditar prompts usando push-to-talk.

Prompts falados costumam ter mais contexto porque você explica naturalmente o problema, as restrições e o objetivo.

Requer uma conta Claude.ai.

Dica avançada complementar

Depois de ditar, peça ao Claude para transformar sua fala em uma especificação curta antes de implementar. Voz é excelente para contexto; especificação escrita é melhor para execução controlada.

24. Após duas correções na mesma coisa, comece do zero

Se o Claude tentou corrigir o mesmo problema duas vezes e falhou, a sessão provavelmente acumulou hipóteses ruins.

Nesse caso, use /clear e escreva um prompt novo com o que foi aprendido.

Dica avançada complementar

Antes de recomeçar, peça um mini post-mortem: hipótese inicial, por que falhou, evidências encontradas e nova hipótese. Esse resumo vira o prompt limpo da próxima tentativa.

25. Diga ao Claude exatamente quais arquivos olhar

Use @ para referenciar arquivos diretamente.

@src/auth/middleware.ts tem o tratamento de sessão.
Verifique também @src/auth/jwt.ts e @src/users/user.service.ts.

Isso evita que o Claude gaste tokens procurando arquivos que você já sabe que são relevantes.

Dica avançada complementar

Forneça arquivos em camadas: “comece por estes 3 arquivos; se precisar, procure chamadas relacionadas”. Isso mantém foco sem impedir investigação quando houver dependências escondidas.

26. Explore código desconhecido com prompts vagos

Nem todo prompt precisa ser específico. Ao entrar em uma base nova, perguntas abertas podem revelar problemas que você não saberia perguntar.

Exemplos:

O que você melhoraria neste arquivo?

Explique os riscos deste módulo.

Quais partes deste código parecem frágeis?

Dica avançada complementar

Use prompts vagos em modo leitura. Depois transforme os achados em tarefas concretas com impacto, evidência, arquivo, risco e proposta de correção.

27. Edite planos com Ctrl+G

Quando o Claude apresenta um plano, você pode usar Ctrl+G para abrir o plano no editor e ajustá-lo diretamente.

Isso é útil quando o plano está quase certo, mas precisa de pequenas restrições ou mudança de ordem.

Dica avançada complementar

Adicione uma seção “não fazer” ao plano. Exemplos: “não alterar schema”, “não mexer em auth”, “não adicionar dependências”, “não tocar em contratos públicos”. Restrições negativas reduzem efeitos colaterais.

28. Execute /init, depois corte o resultado pela metade

CLAUDE.md é o arquivo de instruções persistentes do projeto. Ele pode conter comandos de build, padrões de código, estrutura do repositório, regras de revisão e decisões arquiteturais.

/init gera uma versão inicial com base no projeto, mas normalmente ela vem grande demais.

Veja também: como escrever um ótimo arquivo CLAUDE.md.

Dica avançada complementar

Mantenha no CLAUDE.md apenas o que muda o comportamento do agente: comandos, arquitetura, convenções, validações e regras de segurança. Remova descrições óbvias que ele consegue inferir lendo arquivos.

29. Faça o teste decisivo para cada linha do CLAUDE.md

Para cada linha, pergunte: “o Claude cometeria um erro sem isso?”

Se a resposta for não, a linha provavelmente é ruído.

Um CLAUDE.md grande demais dilui as instruções importantes.

Dica avançada complementar

Classifique cada linha como comando, arquitetura, estilo, segurança ou workflow. Se uma categoria crescer demais, mova detalhes para arquivos de regras, Skills ou imports.

30. Após um erro, peça para atualizar o CLAUDE.md

Quando o Claude errar algo que não deveria repetir, diga:

Atualize o CLAUDE.md para que esse erro não aconteça novamente.

Com o tempo, o arquivo se torna um documento vivo baseado em erros reais do projeto.

Dica avançada complementar

Peça regras observáveis. “Sempre rode pnpm test:unit após alterar services” é melhor do que “tenha cuidado com testes”. Instruções vagas são menos confiáveis.

31. Use .claude/rules/ para regras que se aplicam apenas às vezes

Coloque regras específicas em arquivos markdown dentro de .claude/rules/.

Você pode carregar regras apenas para arquivos específicos usando frontmatter:

---
paths:
  - "**/*.ts"
---

# Convenções TypeScript

Prefira interfaces quando elas representarem contratos públicos.

Dica avançada complementar

Crie rules por domínio: auth.md, payments.md, database.md, frontend.md. Regras sensíveis carregam apenas quando o contexto exige.

32. Use @imports para manter o CLAUDE.md enxuto

Você pode referenciar arquivos auxiliares como @docs/git-instructions.md, @README.md, @package.json ou arquivos pessoais em @~/.claude/.

Isso mantém o arquivo principal curto, mas permite carregar contexto adicional quando necessário.

Dica avançada complementar

Mantenha no CLAUDE.md principal um índice claro dizendo quando consultar cada import. Exemplo: “consulte @docs/deploy.md apenas quando a tarefa envolver deploy”.

33. Coloque comandos seguros na allowlist com /permissions

/permissions permite gerenciar quais comandos o Claude pode executar sem pedir aprovação.

Isso evita aprovar manualmente comandos repetitivos como lint, testes e status.

Dica avançada complementar

Monte allowlist por intenção, não por comodidade. Libere comandos como npm test, pnpm lint e git status. Mantenha aprovação manual para deploy, banco de dados, remoção de arquivos, rede externa e infraestrutura.

34. Use /sandbox quando quiser que o Claude trabalhe com mais autonomia

/sandbox ativa isolamento em nível de sistema operacional. Escritas ficam restritas ao projeto, e conexões de rede podem ser limitadas a domínios aprovados.

No macOS, isso usa Seatbelt; no Linux, bubblewrap. A restrição vale também para subprocessos criados por comandos do Claude.

Dica avançada complementar

Para tarefas longas ou sem supervisão, prefira Docker ou ambiente descartável. Sandboxing reduz risco, mas não substitui revisão humana quando há autenticação, pagamento, migração, infraestrutura ou dados sensíveis.

35. Crie subagentes personalizados para tarefas recorrentes

Subagentes personalizados são agentes pré-configurados salvos em .claude/agents/.

Você pode criar um agente de revisão de segurança, um agente de busca rápida, um agente de documentação ou um agente de testes.

Use:

/agents

Dica avançada complementar

Limite ferramentas por função. Um agente de segurança pode ser somente leitura; um agente de documentação não precisa de Bash; um agente de migração deve rodar em worktree isolado.

36. Escolha os servidores MCP certos para sua stack

Comece com servidores MCP que realmente adicionam contexto externo útil.

Bons exemplos:

• Playwright para testes de navegador e UI;
• PostgreSQL/MySQL para consulta de schema;
• Slack para bugs e threads de contexto;
• Figma para design-to-code.

Veja também: melhores servidores MCP em 2026.

Dica avançada complementar

Use MCP quando o contexto vive fora do repositório ou muda com frequência. Para regras estáveis, prefira CLAUDE.md, rules ou Skills. MCP demais aumenta ruído, permissões e superfície de risco.

37. Defina seu estilo de saída

Use /config para escolher como o Claude responde.

Estilos comuns:

• Explicativo — detalhado, passo a passo;
• Conciso — breve e direto;
• Técnico — preciso e com jargão.

Você também pode criar estilos personalizados em ~/.claude/output-styles/.

Dica avançada complementar

Crie estilos por tarefa: “review-sênior”, “debug-direto”, “explicação-júnior” e “arquitetura”. Isso evita repetir instruções de tom e formato a cada sessão.

38. Use CLAUDE.md para sugestões, hooks para requisitos

CLAUDE.md é consultivo. O Claude pode seguir, mas não é uma garantia absoluta.

Hooks são determinísticos. Se algo precisa acontecer sempre, use hook.

Exemplos:

• Rodar Prettier após editar arquivo;
• Bloquear rm -rf;
• Impedir escrita em migrations;
• Rodar lint após alterações.

Dica avançada complementar

Use esta divisão: orientação vai no CLAUDE.md; execução obrigatória vai em hook; conhecimento sob demanda vai em Skill; ferramenta externa vai em MCP.

39. Formate automaticamente com um hook PostToolUse

Você pode rodar Prettier ou outro formatador toda vez que o Claude editar um arquivo.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

O || true evita que uma falha de formatação bloqueie totalmente o fluxo.

Dica avançada complementar

Evite formatar o projeto inteiro. Formate apenas o arquivo alterado ou o pacote afetado. Isso reduz diffs gigantes e facilita revisão humana.

40. Bloqueie comandos destrutivos com hooks PreToolUse

Use hooks para bloquear comandos perigosos antes da execução.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "type": "command",
        "command": "if echo \"$TOOL_INPUT\" | grep -qE 'rm -rf|drop table|truncate'; then echo 'BLOQUEADO: comando destrutivo' >&2; exit 2; fi"
      }
    ]
  }
}

Adicione isso em .claude/settings.json ou configure interativamente com /hooks.

Dica avançada complementar

Inclua padrões destrutivos específicos da sua stack: prisma migrate reset, typeorm schema:drop, kubectl delete, terraform destroy, docker system prune e comandos de deploy.

41. Preserve contexto importante durante a compactação com hooks

Durante sessões longas, a compactação pode remover detalhes importantes. Um hook pode reinjetar informações essenciais após compactação.

Peça ao Claude:

Configure um hook de notificação que, após compactação,
lembre a tarefa atual, os arquivos modificados,
as restrições e o status dos testes.

Dica avançada complementar

Mantenha um arquivo .claude/session-state.md com objetivo, plano, arquivos alterados, testes executados e pendências. Um hook pode atualizar esse arquivo e usá-lo para recuperar contexto.

42. Sempre revise manualmente auth, pagamentos e mutações de dados

Claude Code é útil, mas algumas áreas exigem revisão humana obrigatória:

• autenticação;
• autorização;
• pagamentos;
• webhooks;
• mutações de dados;
• migrações;
• operações destrutivas no banco.

Um erro nessas áreas pode custar dinheiro, segurança, dados ou confiança.

Dica avançada complementar

Crie um checklist humano obrigatório para áreas críticas: escopo de permissão, idempotência, rollback, transações, concorrência, auditoria, logging e dados sensíveis.

43. Use /branch para tentar uma abordagem diferente sem perder a atual

/branch ou /fork cria uma cópia da conversa no ponto atual.

Use quando quiser testar uma abordagem alternativa sem destruir o caminho original.

Dica avançada complementar

Use branches conversacionais para comparar estratégias: “abordagem simples”, “abordagem performática”, “sem dependências” e “mais segura”. Depois peça uma tabela comparando risco, diff, manutenção e testes necessários.

44. Deixe o Claude entrevistá-lo quando você não consegue especificar completamente uma feature

Se você sabe o que quer, mas não sabe especificar todos os detalhes, peça para o Claude fazer perguntas.

Quero construir [breve descrição]. Me entreviste detalhadamente
usando a ferramenta AskUserQuestion. Pergunte sobre implementação técnica,
casos extremos, preocupações e tradeoffs. Não faça perguntas óbvias.
Continue entrevistando até cobrir tudo,
depois escreva uma especificação completa em SPEC.md.

Dica avançada complementar

Depois que o SPEC.md estiver pronto, abra uma nova sessão para implementação. A sessão de entrevista é ótima para descoberta, mas pode poluir o contexto da execução com hipóteses descartadas.

45. Faça um Claude escrever, outro Claude revisar

Uma sessão implementa. Outra sessão, com contexto limpo, revisa como engenheiro sênior.

Isso funciona bem porque o revisor não carrega as justificativas do implementador.

A mesma ideia funciona com TDD:

• Sessão A escreve testes;
• Sessão B implementa código para passar nos testes.

Dica avançada complementar

Dê ao revisor um papel adversarial, mas objetivo: procurar bugs reais, regressões, falhas de segurança, quebra de contrato e ausência de testes. Evite pedir revisão genérica demais, pois ela pode virar cosmética.

46. Revise PRs de forma conversacional

Em vez de pedir uma revisão de PR de uma vez, converse com o Claude sobre pontos específicos.

Exemplos:

• Qual mudança é mais arriscada neste PR?
• O que quebra se isso rodar de forma concorrente?
• O tratamento de erros segue o padrão do projeto?
• Os testes cobrem o caminho crítico?

Dica avançada complementar

Revise por camadas: contrato de API, persistência, segurança, performance, tratamento de erro, testes e UX. Essa abordagem encontra problemas que revisões genéricas costumam perder.

47. Nomeie e codifique por cores suas sessões

Use:

/rename auth-refactor
/color blue

Isso ajuda quando você trabalha com várias sessões paralelas.

Cores disponíveis incluem red, blue, green, yellow, purple, orange, pink e cyan.

Dica avançada complementar

Crie uma convenção: vermelho para produção/risco, azul para feature, verde para testes, roxo para pesquisa e amarelo para revisão. Isso reduz erro humano quando há muitos terminais abertos.

48. Toque um som quando o Claude terminar

Você pode configurar um hook Stop para tocar um som quando o Claude concluir uma resposta.

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/bin/afplay /System/Library/Sounds/Glass.aiff"
          }
        ]
      }
    ]
  }
}

Dica avançada complementar

Use notificações apenas em tarefas longas. Se tudo apitar, vira ruído. Bons casos: builds demorados, suites de teste, deploys, revisão grande e operações em lote.

49. Use fan-out com claude -p para operações em lote

O modo não interativo permite rodar o Claude em lote sobre arquivos independentes.

for file in $(cat files-to-migrate.txt); do
  claude -p "Migre $file de class components para hooks" \
    --allowedTools "Edit,Bash(git commit *)" &
done
wait

Isso é útil para migrações repetitivas, atualização de imports, conversão de formatos e alterações independentes por arquivo.

Dica avançada complementar

Use fan-out apenas quando os arquivos são independentes. Antes de rodar em lote, execute uma amostra com 3 arquivos, revise o padrão gerado e só depois escale. Sempre limite ferramentas com --allowedTools.

50. Personalize os verbos do spinner

Enquanto o Claude pensa, o terminal exibe verbos no spinner. Você pode personalizá-los.

Exemplo:

Substitua meus verbos do spinner nas configurações do usuário por estes:
Alucinando com responsabilidade,
Fingindo pensar,
Chutando com confiança,
Culpando a janela de contexto

Você também pode pedir uma vibe específica, como “feitiços de Harry Potter” ou “piadas de desenvolvedor cansado”.

Dica avançada complementar

Personalizar spinner é divertido, mas a personalização mais útil é a statusline. Mostre modelo, branch, diretório, permissões e uso de contexto. Isso melhora produtividade de verdade.

Tabela de Comandos Essenciais e Melhores Práticas