2.5 Selecting Built-in Tools

The previous lessons were about tools you design or connect. This one is about the six tools that come built into Claude Code from the start — the ones it uses to work with a codebase: Read, Write, Edit, Bash, Grep, and Glob. Task Statement 2.5 tests whether you can pick the RIGHT one for a job, because choosing wrong wastes time and, more importantly, wastes context (the precious budget you'll learn to protect in Domain 5).

Why does the choice matter so much? Because these tools are not interchangeable, and using the wrong one is like reaching for a sledgehammer to hang a picture. Reading an entire 2,000-line file into context just to find one function is enormously wasteful when a targeted search would have found it instantly. The exam rewards the efficient instinct: search precisely, read only what you need, edit surgically.

Let's group the six by what they're for: two for FINDING things (Grep, Glob), two for READING and WRITING whole files (Read, Write), one for SURGICAL edits (Edit), and one for running commands (Bash). The two that cause the most confusion — and that the exam loves — are Grep and Glob, so we'll spend the most time there.

This is the distinction the exam tests most, and there's a one-line memory hook that settles it: Grep finds what's INSIDE files; Glob finds files by their NAMES. Get that straight and most 2.5 questions answer themselves.

Use GREP when you're searching the CONTENTS of files — you want to find every place a function is called, locate an error message, or find all the files that import a certain module. Grep reads inside files looking for a pattern of text. Use GLOB when you're searching by file PATH or NAME — you want all the test files (**/*.test.tsx), every TypeScript file, or everything in a certain directory. Glob never looks inside a file; it just matches names and paths.

The classic trap inverts them. 'Find all the callers of this function' tempts people toward Glob, but callers live INSIDE files (it's their content you're after) — that's Grep. 'Find all the test files' tempts people toward Grep, but you're matching a NAME pattern — that's Glob. Whenever you're choosing, ask: am I looking for something INSIDE files (Grep) or for files BY NAME (Glob)?

For changing a file, you have two options, and the exam rewards reaching for the lighter one first. EDIT is the default for modifications: you give it a unique piece of text to find and what to replace it with, and it makes a surgical change without touching the rest of the file. It's precise and cheap.

Edit has one failure mode worth knowing: it needs the text you're matching to be UNIQUE in the file. If the anchor text appears multiple times, Edit can't tell which one you mean and fails. The right response is NOT to abandon Edit — it's to widen the anchor (include more surrounding text to make it unique) or use a replace-all option if you genuinely mean every occurrence. Only when Edit truly can't get a unique match do you fall back to Read + Write: read the whole file, then write the whole file back with your change.

Why is Read+Write the LAST resort rather than the default? Because it's expensive: reading an entire file pulls all of it into context, burning tokens, and the exam explicitly penalizes defaulting to Read+Write when a surgical Edit would do. Reserve the heavy approach for when the surgical one genuinely can't work.

The single most important habit with built-in tools is to explore a codebase INCREMENTALLY rather than reading everything up front. This isn't just tidiness — reading whole files you don't need floods your context and degrades the agent's reasoning (the attention and context problems from Domain 1.6 and Domain 5). Efficient discovery is a sequence of precise, narrowing steps.

The pattern: start with Grep to find entry points (where is this function defined? where's this route handled?). Then Read just those spots to follow the imports and trace the flow. Then Grep again for how the things you found are used. You pull in only what each step actually needs, never the whole codebase. A concrete trace: to understand a deprecated function, Grep for its definition, use Glob to find its sibling test files, then Grep again for the wrapper names that call it — 'Grep, then Glob, then Grep again,' not 'Glob everything first' and certainly not 'Read every file.'

This ties the whole domain together: precise tool selection (Grep vs Glob, Edit vs Read+Write) in service of incremental discovery is how an agent works through a large codebase without drowning its own context. Reading all files upfront is the cardinal sin the exam punishes.

The 2.5 traps are almost all tool-selection inversions (Grep vs Glob) or efficiency failures (Read+Write or read-everything when something lighter would do). Anchor on 'inside files = Grep, file names = Glob' and 'surgical first, heavy last.'

• •Glob to find callers. ✗ Using Glob to find who calls a function. ✓ Callers are content INSIDE files → Grep.
• •Grep for extensions. ✗ Using Grep to find all .test.tsx files. ✓ That's a NAME pattern → Glob.
• •Reading all files upfront. ✗ Loading the whole codebase to understand it. ✓ Incremental discovery: Grep → Read → Grep.
• •Defaulting to Read+Write. ✗ Read+Write for a small change, or jumping to it on the first non-unique Edit match. ✓ Edit by default; on non-unique match widen the anchor or replace-all; Read+Write only as a true last resort.

You now know the six built-in tools, the Grep-vs-Glob distinction, when Edit beats Read+Write, and the incremental-discovery habit. The exercise has you trace a function through a codebase using exactly the right tool at each step — and feel how much context you save by not reading everything.

That completes Domain 2 — you can now design tool interfaces (2.1), make them fail recoverably (2.2), distribute and control them (2.3), integrate external MCP servers (2.4), and wield the built-in tools efficiently (2.5). Domain 3 shifts from tools to configuring Claude Code itself — CLAUDE.md, skills, rules, plan mode, and CI/CD.