Tips e Atalhos
Dicas práticas que não cabem bem em nenhum capítulo específico mas que fazem diferença no uso diário. Algumas são óbvias em retrospecto, outras levam semanas pra descobrir sozinho.
Sessões e Contexto
Buscar histórico de conversas antigas
Todas as sessões ficam salvas em ~/.claude/projects/. Você pode buscar por assunto:
# Busca em todas as sessões do projeto atual
grep -r "nome do que você lembra" ~/.claude/projects/$(pwd | sed 's|/|-|g')
# Busca em todos os projetos
grep -r "jwt refresh" ~/.claude/projects/
# Ver estrutura de sessões
ls ~/.claude/projects/
Útil quando você lembra que resolveu um problema similar num projeto anterior mas não lembra qual sessão era.
Você também pode pedir diretamente no Claude:
Nas nossas conversas anteriores sobre autenticação, o que ficou decidido sobre refresh token?
Ele busca no auto memory e no histórico disponível.
HANDOFF.md — passagem entre sessões
Quando você vai encerrar uma sessão no meio de uma tarefa e quer retomar depois sem perder contexto, peça um handoff antes de fechar:
Antes de fechar, escreve um HANDOFF.md com:
- O que foi feito até aqui
- O que falta fazer e em que ordem
- Decisões que tomamos e por quê
- Arquivos que foram modificados
- O que testar antes de continuar
Na próxima sessão:
claude -n "feat/continuacao"
Lê o HANDOFF.md e continua de onde paramos.
Funciona melhor que tentar resumir de memória o que estava acontecendo. Especialmente em features longas que ficam abertas por dias.
/fork — clonar a conversa pra testar outra abordagem
Quando o Claude está indo numa direção e você quer testar uma alternativa sem perder o que tem:
/fork
Cria uma cópia da sessão atual a partir desse ponto. Você testa a abordagem B na cópia, compara os resultados, e decide qual manter. A sessão original continua intacta.
Útil quando a implementação chegou num ponto de bifurcação — tipo "faço com Redis ou com banco?" — e você quer ver as duas antes de decidir.
Gerenciar múltiplas instâncias em paralelo
Pra trabalhar em 3-4 tarefas em paralelo (features, bugfixes, pesquisa simultânea), o padrão que funciona é abrir cada instância numa aba de terminal separada com nome descritivo:
# Aba 1 — feature principal
claude -n "feat/auth-refresh"
# Aba 2 — bugfix urgente em paralelo
claude -n "fix/payment-null"
# Aba 3 — pesquisa / exploração
claude -n "research/redis-strategy"
Fluxo: varre da esquerda pra direita nas abas, despacha a próxima ação em cada sessão e passa pra seguinte enquanto a anterior está rodando. Cada sessão tem contexto próprio, histórico próprio.
Evita o anti-padrão de ficar alternando de assunto na mesma sessão (que polui o contexto das duas tarefas).
Atalhos de Teclado
A maioria dos devs usa o Claude Code só com Enter e Esc. Esses atalhos mudam a ergonomia:
Navegação no input
| Atalho | O que faz |
|---|---|
Ctrl+A | Vai pro início da linha |
Ctrl+E | Vai pro final da linha |
Option+← / Option+→ | Move palavra por palavra |
Ctrl+W | Apaga a palavra anterior |
Ctrl+U | Apaga a linha inteira |
Ctrl+G | Abre o input no seu editor de texto |
Ctrl+G é o mais subutilizado: quando você vai escrever um prompt longo ou estruturado, abre no editor em vez de digitar direto no terminal.
Multi-linha sem enviar
\ + Enter
Quebra de linha sem enviar o prompt. Pra prompts estruturados com passos numerados ou listas:
Implemente o endpoint de login seguindo esses passos:\
1. Valida o body com Zod\
2. Busca o usuário no banco\
3. Compara o hash da senha\
4. Gera o JWT e o refresh token\
5. Salva o refresh token no Redis com TTL de 7 dias\
6. Retorna os tokens no body
Mover processo pro background
Ctrl+B
Move o comando que está rodando pro background. Você continua usando o terminal enquanto ele processa. Útil pra builds longos, suítes de teste pesadas, ou qualquer tarefa que demora.
Colar imagem diretamente
Ctrl+V (ou Cmd+V no macOS) cola imagem do clipboard direto no chat. Screenshots de erro, de UI, de diagrama — sem precisar salvar o arquivo antes.
Qualidade e Verificação
TDD com Claude — escreva o teste primeiro
Em vez de pedir pra implementar e depois testar, inverta:
Quero implementar validação de CPF. Antes de qualquer código:
1. Escreve os casos de teste que a função precisa passar
2. Mostra os casos e me aguarda aprovar
3. Depois implementa a função até os testes passarem
Vantagem dupla: você aprova o comportamento esperado antes de ver o código, e o Claude tem um critério de verificação claro sem você precisar inventar. Os testes viraram o spec.
Funciona especialmente bem pra lógica de negócio, validações e transformações de dados.
Self-check antes de entregar
Quando a tarefa é complexa e você quer que o Claude se auto-audite antes de chamar você:
Depois de implementar, faça isso antes de me chamar:
1. Rode os testes e corrija qualquer falha
2. Monte uma tabela de verificação: | Critério | Status | Observação |
cobrindo cada item do que foi pedido
3. Só me chame depois que a tabela estiver toda verde
Reduz a quantidade de vezes que você recebe "está pronto" e descobre que falta alguma coisa.
Referência de arquivo entre diretórios
Quando você está numa sessão e precisa referenciar um arquivo fora do diretório atual:
realpath ../outro-projeto/src/auth/jwt.ts
# /Users/bruno/projetos/outro-projeto/src/auth/jwt.ts
Cole o caminho absoluto no prompt. O Claude usa Read com caminho absoluto sem problema, mesmo sendo fora do working directory atual.
PR draft antes de finalizar
Antes de pedir um PR "de verdade", abra um draft:
Cria um draft PR com o que temos até agora. Título provisório, body com o que foi feito e o que falta.
gh pr create --draft --title "feat: auth refresh (WIP)" --body "..."
Draft não bloqueia ninguém, aparece no board, e você consegue ver o diff no GitHub em vez de só no terminal. Muito mais fácil revisar antes de pedir review.
Produtividade
Input por voz
Digitar prompts longos é lento. Ferramentas de transcrição local resolvem isso:
- SuperWhisper (macOS) — transcrição local com hotkey global, funciona em qualquer campo de texto
- Whisper.cpp — versão open-source, roda localmente, sem enviar áudio pra nenhum servidor
A diferença de velocidade pra prompts descritivos é real. Falar "leia o arquivo de rotas, entenda como os handlers funcionam, e me explica como adicionar um novo endpoint seguindo o padrão existente" é muito mais rápido que digitar.
Aliases pra acesso rápido
# ~/.bashrc ou ~/.zshrc
alias c='claude'
alias cc='claude --continue'
alias cr='claude --resume'
alias ch='claude --chrome' # abre integração com browser
cc retoma a última sessão do diretório atual sem picker. Pra workstreams que ficam abertos o dia todo, isso economiza bastante fricção.
/stats — histórico de uso
/stats
Mostra um gráfico de barras da sua atividade por dia. Útil pra entender padrões de uso do time ou pra justificar o investimento em reunião.
Buscar feature que você não sabe que existe
Em vez de ir pra documentação, pergunte direto:
Existe alguma forma de fazer X no Claude Code que eu possa não conhecer?
ou
/release-notes
O próprio Claude Code tem acesso ao histórico de mudanças e conhece as features mais recentes. É a forma mais rápida de descobrir funcionalidade nova.
Segurança e Experimentos
Container pra tarefas arriscadas ou longas
Pra tarefas onde você quer que o Claude tenha mais autonomia mas não quer risco no sistema principal — migration de dados, script destrutivo, experimento com dependência desconhecida:
# Roda o Claude Code em container com o código montado
docker run -it --rm \
-v $(pwd):/app \
-w /app \
-e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
node:22 \
npx @anthropic-ai/claude-code --dangerously-skip-permissions
--dangerously-skip-permissions desliga todos os checks de permissão. Em container descartável é seguro — se der errado, o container some. No seu sistema local, nunca.
Alternativa mais simples com worktree isolado:
git worktree add /tmp/experimento-$(date +%s) -b experimento/teste
cd /tmp/experimento-*
claude --permission-mode bypassPermissions
Trabalho experimental fica isolado. Se o Claude bagunçar tudo, o worktree some e o branch principal não foi tocado.
Auditoria de comandos aprovados
Com o tempo, sua allowlist em settings.json pode acumular permissões que você aprovou uma vez e esqueceu. Vale revisar periodicamente:
# Ver o que está liberado no projeto atual
cat .claude/settings.json
# Ver o que está liberado globalmente
cat ~/.claude/settings.json
Procure por comandos que parecem muito abertos (ex: Bash(*) em vez de Bash(npm test)) e que você não lembra por que aprovou.
CLAUDE.md
Manter o CLAUDE.md enxuto com auto-revisão
Com o tempo o CLAUDE.md cresce. Pra limpar sem perder o que importa:
Leia o CLAUDE.md atual e o histórico recente das nossas conversas.
Identifique:
1. Regras que o código já deixa óbvias (podem sair)
2. Regras que aparecem em todo projeto (genéricas demais)
3. Regras que você nunca precisou invocar (provavelmente obsoletas)
4. O que está faltando baseado nos problemas que apareceram
Proponha uma versão enxuta com no máximo 150 linhas.
Faça isso a cada 2-3 meses ou quando o CLAUDE.md passar de 200 linhas.
Comentários HTML não gastam token
Você pode adicionar notas de manutenção no CLAUDE.md que não entram no contexto:
<!--
Essa regra existe porque o Drizzle não suporta .returning() no SQLite.
Quando migrarmos pro Postgres isso pode ser removido.
Revisão: 2026-08
-->
Use `select` após `insert` em vez de `.returning()`.
O comentário aparece pra você quando abre o arquivo, mas não conta token na sessão.
Prompts
Negative constraints — diga o que não quer
Uma das técnicas mais subestimadas. Especificar o que o Claude não deve fazer muitas vezes produz resultado melhor do que descrever o que deve:
# Sem constraint
"Implemente autenticação"
# Com negative constraints
"Implemente autenticação. Não use bibliotecas externas além do que já está no projeto.
Não modifique os testes existentes. Não crie novos arquivos — só edite os que já existem."
Outros exemplos úteis:
"Refatore esse componente. Não mude o comportamento externo — só a estrutura interna."
"Corrija o bug. Não faça nenhuma mudança além do mínimo necessário pra corrigir."
"Otimize essa query. Não mude o schema do banco."
"Adicione validação. Não altere a interface pública da função."
Negative constraints são especialmente úteis quando você tem medo de que o Claude "aproveite" a tarefa pra fazer refatoração não solicitada ou mudar mais do que deveria.
Peça formato de saída explicitamente
Claude adapta o formato da resposta quando você especifica. Pra usar a saída em scripts ou pipelines:
# Saída JSON pra processar depois
claude -p "liste todos os endpoints de API" --output-format json
# Saída streaming JSON pra pipelines em tempo real
claude -p "analise esse log e classifique os erros" --output-format stream-json
# Texto simples, sem markdown
claude -p "explique o que faz essa função" --output-format text
stream-json emite cada evento como um objeto JSON numa linha separada assim que é gerado. Útil em CI/CD onde você quer processar output antes que a sessão termine:
claude -p "revise esse PR" --output-format stream-json | \
grep '"type":"text"' | \
python3 -c "import sys,json; [print(json.loads(l)['text']) for l in sys.stdin]"
Encadeie prompts em vez de um prompt gigante
Pra tarefas complexas, prompts encadeados em sequência produzem resultado mais consistente do que um prompt monolítico:
# Prompt 1 — entenda
"Leia src/payment/ e explique como o fluxo de cobrança funciona hoje."
# Prompt 2 — planeje (depois de ler a explicação)
"Dado o que você entendeu, proponha como adicionar suporte a PIX sem quebrar o fluxo existente."
# Prompt 3 — implemente (depois de aprovar o plano)
"Implemente o plano aprovado. Comece pelo passo 1."
A alternativa de jogar tudo num prompt só funciona em tarefas simples. Em tarefas que envolvem entendimento do codebase + decisão de arquitetura + implementação, o encadeamento ganha.
Multi-Agente
Um agente, uma tarefa
A regra mais importante pra multi-agente: cada sessão tem uma responsabilidade única. Misturar tarefas na mesma sessão degrada qualidade das duas.
❌ Errado:
Sessão única: "Implemente o endpoint de login, escreva os testes, refatore o módulo de auth que está feio, e revise o PR do João."
✅ Certo:
Sessão A: "Implemente o endpoint de login"
Sessão B: "Revise o PR #123 do João" (em paralelo)
Sessão C: "Refatore src/auth/" (depois das outras)
Pipeline Architect → Implementation → QA
O padrão mais produtivo pra features que envolvem decisão de design:
Sessão 1 — Architect (Opus):
/model opus
Analise o codebase e crie um plano de implementação para [feature].
Documente em SPEC.md: decisões de design, arquivos afetados, ordem de implementação, riscos.
Não escreva nenhum código.
Sessão 2 — Implementation (Sonnet):
claude -n "impl/feature-x"
Leia SPEC.md e implemente exatamente o que está especificado.
Não tome decisões de design — se encontrar ambiguidade, consulte-me antes de escolher.
Sessão 3 — QA (Sonnet, em paralelo com sessão 2 após primeiros commits):
claude -n "qa/feature-x"
Revise o código da branch feature/x. Procure: edge cases não cobertos pelos testes,
inconsistências com SPEC.md, problemas de segurança, comportamento em concorrência.
Não implemente nada — só reporte.
Sessões 2 e 3 podem rodar em paralelo depois que há código suficiente pra revisar. O QA não está enviesado por ter escrito o código, então pega coisas que o autor não pegaria.
Modelo certo pra cada função
| Tarefa | Modelo | Motivo |
|---|---|---|
| Decisão de arquitetura, design de sistema | Opus | Raciocínio profundo vale o custo |
| Implementação de feature, refatoração | Sonnet | Boa relação custo/qualidade |
| Fixes pontuais, formatação, renomear | Haiku | Tarefa mecânica, não precisa de modelo pesado |
| Sumarização de logs, classificação | Haiku | Alta velocidade, baixo custo |
| Code review, análise de segurança | Opus ou Sonnet | Depende da criticidade |
Trocar de modelo mid-session: /model haiku. Definir pra subagente no frontmatter: model: haiku.
Usar Opus pra tudo que Sonnet resolve bem é onde a maior parte do custo desnecessário de times vem.
Monitorar custo por agente
Em times com múltiplas sessões paralelas, é fácil perder o controle de custo. Em cada sessão:
/cost
Mostra tokens e custo estimado da sessão atual. Se uma sessão está acima do esperado, quase sempre é um dos problemas:
- Output de comando entrando cru (falta hook de filtro)
- CLAUDE.md inflado sendo recarregado com frequência
- Modelo errado pra tarefa (Opus fazendo o que Sonnet faria)
- Sessão "kitchen sink" com tarefas misturadas
Skills Auto-Activation
O Claude pode invocar uma skill automaticamente quando entende que o contexto bate com a descrição dela — você não precisa digitar /skill-name se a description no frontmatter for boa.
O campo description é o que o modelo usa pra decidir se invoca. Escreva como "quando usar", não como "o que é":
---
name: api-review
description: >
Use quando o usuário criar ou modificar endpoints de API REST.
Verifica: autenticação, validação de input, formato de resposta de erro,
rate limiting, e documentação OpenAPI.
---
vs.
---
name: api-review
description: Revisa endpoints de API # genérico demais — não vai auto-ativar bem
---
Quanto mais específico o gatilho na description, mais precisa a auto-ativação. Pra skills que têm side effects (deploy, commit, envio de mensagem), use disable-model-invocation: true — elas nunca devem ativar sozinhas.
Referências: