Built-in tools: Read, Write, Edit, Bash, Grep e Glob
Objetivos de aprendizagem
- Selecionar
Greppara busca de conteúdo eGlobpara padrões de caminho/nome de arquivo. - Usar
Read/Writepara operações de arquivo inteiro eEditpara modificações pontuais por correspondência de texto única. - Aplicar o fallback
Read+WritequandoEditfalha por match não único. - Construir entendimento do codebase incrementalmente: começar com
Grepnos pontos de entrada e seguir imports comRead, em vez de ler tudo de antemão. - Rastrear uso de funções através de módulos wrapper: identificar os nomes exportados e buscar cada um no codebase.
Qual ferramenta para qual pergunta
| Ferramenta | Responde a | Exemplo |
|---|---|---|
Grep | "Onde este conteúdo aparece?" — padrões dentro dos arquivos | Achar callers de calculateTax, mensagens de erro, imports |
Glob | "Quais arquivos têm este nome/caminho?" — padrões de path | **/*.test.tsx, src/**/config*.json |
Read | Conteúdo completo (ou trecho) de um arquivo conhecido | Ler um módulo para seguir seus imports |
Write | Criar arquivo ou sobrescrever por inteiro | Gravar a versão nova completa |
Edit | Modificação pontual por correspondência de texto única | Trocar uma linha específica |
Bash | Comandos de shell (build, testes, git) | npm test, git diff |
Mnemônico da prova: Grep = conteúdo, Glob = caminho. "Encontrar todos os arquivos de teste" é Glob; "encontrar onde a função é chamada" é Grep.
Edit exige match único — e o fallback Read + Write
Edit substitui um trecho localizado por correspondência exata de texto. Se o texto-âncora aparece 0 vezes (âncora errada/desatualizada) ou mais de 1 vez (âncora ambígua), a edição falha — de propósito, para não alterar o lugar errado. Estratégias, em ordem:
- Ampliar a âncora com linhas vizinhas até ficar única.
- Quando não dá para tornar a âncora única de forma confiável:
Readdo arquivo inteiro +Writedo conteúdo completo modificado — o fallback determinístico cobrado no exame.
O mesmo contrato aparece na text editor tool da API (str_replace: erro se 0 ou >1 ocorrências). Handler de referência:
from pathlib import Path
def str_replace(path: str, old_str: str, new_str: str) -> dict:
"""Contrato do Edit/str_replace: exatamente 1 ocorrencia, senao erro."""
text = Path(path).read_text(encoding="utf-8")
count = text.count(old_str)
if count == 0:
return {
"is_error": True,
"content": "Nenhuma ocorrencia da ancora. Releia o arquivo (Read) "
"e use uma ancora atualizada, ou caia para Read + Write.",
}
if count > 1:
return {
"is_error": True,
"content": f"{count} ocorrencias da ancora (ambigua). Amplie a ancora "
"com linhas vizinhas ou use Read + Write do arquivo inteiro.",
}
Path(path).write_text(text.replace(old_str, new_str, 1), encoding="utf-8")
return {"is_error": False, "content": "Edicao aplicada com sucesso."}
# Fallback deterministico quando a ancora nao pode ser tornada unica:
def read_write_fallback(path: str, transform) -> None:
original = Path(path).read_text(encoding="utf-8")
Path(path).write_text(transform(original), encoding="utf-8")
Exploração incremental do codebase
Ler todos os arquivos de antemão estoura o contexto e dilui a atenção. O fluxo eficiente é incremental:
flowchart TD
A[Grep: localizar pontos de entrada\nex.: nome da função, mensagem de erro] --> B[Read: abrir só os arquivos com hit]
B --> C[Seguir imports relevantes com Read]
C --> D{Entendimento suficiente?}
D -- não --> A
D -- sim --> E[Editar com Edit\nou Read + Write]
- Grep pelo sintoma (nome de função, mensagem de erro, import) para achar pontos de entrada.
- Read apenas nos arquivos com hit; siga os imports que importam para o fluxo.
- Repita Grep→Read conforme novas pistas surgem — nunca "ler tudo primeiro".
Rastreando wrappers: quando um módulo re-exporta funções (barrel files, wrappers), primeiro identifique todos os nomes exportados (Grep por export no módulo), depois faça Grep de cada nome no codebase — buscar só o nome original perde os call sites que usam o nome re-exportado.
Evite usar Bash com find/grep/cat para o que as ferramentas dedicadas fazem: Grep/Glob/Read são otimizadas, seguras para paralelizar e integradas ao sistema de permissões do Claude Code.
Pegadinhas da prova
- Distrator típico: usar
Globpara achar onde uma função é chamada. Glob casa caminhos, não conteúdo — chamadas de função se acham comGrep. - Distrator típico: quando
Editfalha por match duplicado, "rodar o Edit duas vezes" ou "usar replace_all". A resposta cobrada: ampliar a âncora ou cair paraRead+Writedo arquivo inteiro. - Distrator típico: "leia todos os arquivos do diretório antes de começar". Exploração incremental (Grep → Read seguindo imports) preserva contexto e escala.
- Pegadinha:
Writesobrescreve o arquivo inteiro — no fallback, sempreReadantes para partir do conteúdo atual completo. - Pegadinha: rastrear uma função re-exportada buscando apenas o nome original perde os call sites do alias — enumere os exports primeiro.
Resumo em 5 linhas
Grepbusca conteúdo dentro dos arquivos;Globcasa padrões de caminho/nome (**/*.test.tsx).Read/Writeoperam no arquivo inteiro;Editfaz modificação pontual e exige âncora com exatamente 1 ocorrência.- Edit falhou por 0 ou >1 matches? Amplie a âncora; se não der, fallback
Read+Writedo conteúdo completo. - Explore incrementalmente: Grep nos pontos de entrada → Read nos hits → seguir imports; nunca ler o codebase inteiro de antemão.
- Para wrappers/re-exports: primeiro enumere os nomes exportados, depois Grep de cada nome no codebase.
Documentação oficial
- Claude Code — ferramentas disponíveis e settings
- Claude Code — common workflows (explorar codebases)
- Text editor tool (contrato str_replace)
Questões de fixação
1. Você precisa encontrar todos os lugares do codebase que chamam parseInvoice(). Qual ferramenta?
Gabarito: B. Chamadas de função são conteúdo — Grep. A está errada: Glob casa nomes de arquivo, e os callers não têm "parseInvoice" no nome do arquivo. C desperdiça contexto lendo tudo. D é ferramenta de modificação, não de busca — e falharia com múltiplos matches.
2. Edit falhou porque o texto-âncora aparece 3 vezes no arquivo e não há como torná-lo único de forma confiável. Qual é o fallback correto?
Gabarito: C. Read + Write é o fallback determinístico documentado: você parte do conteúdo real atual e grava a versão completa correta. A não resolve — cada execução continua ambígua. B substituiria as 3 ocorrências quando talvez só uma deva mudar. D perde o conteúdo atual do arquivo, que precisa ser a base da modificação.
3. Ao investigar um bug num codebase desconhecido de 800 arquivos a partir de uma mensagem de erro, qual é a primeira ação recomendada?
Gabarito: A. Exploração incremental: Grep localiza onde a mensagem vive, Read segue os imports relevantes. B e D estouram o contexto e diluem a atenção. C lista caminhos, mas não aproxima você do erro — o filtro relevante é por conteúdo.
4. A função validateCpf é re-exportada por um barrel file como validators.cpf. Buscar validateCpf com Grep encontra só 2 usos, mas você suspeita que há mais. Qual abordagem encontra todos os call sites?
Gabarito: D. Com re-exports, os call sites usam o alias (validators.cpf) — enumere os exports do wrapper e busque cada nome. A confunde localização com uso. B não muda nada: o alias tem outro nome, não outra caixa. C é a leitura em massa que a exploração incremental evita.