Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively

Claude Code and the Claude Agent SDK ship a small, fixed set of file and shell tools that every session can use before any MCP server is added: Read, Write, Edit, Bash, Grep, and Glob. Choosing the right one for each step is a tool-selection skill in its own right, and picking the wrong one wastes context, tokens, and turns.

Think of them in three jobs. Discovery: Glob finds files by path or name pattern, Grep searches inside files for content. Reading: Read loads a file's full contents with line numbers. Writing: Write replaces a whole file, Edit makes a targeted in-place change. Bash runs shell commands (build, test, git) and is not a substitute for the search or read tools.

The exam tests that you reach for the tool whose job matches the step: search contents with Grep, match filenames with Glob, change one spot with Edit, rewrite a file with Write, and run commands with Bash. Distractor answers typically swap two of these, for example using Glob to find a function definition, or shelling out to grep in Bash to search the codebase.

Grep is a content search: it looks inside files for a pattern. Use it to find every caller of a function, locate a specific error message string, or find all files that import a module. It is powered by ripgrep, so it takes a regular expression and supports filtering by file glob or type, case-insensitive matching, and context lines. Output modes include files_with_matches (just the paths, the default), content (matching lines, optionally with -n line numbers and -A / -B / -C context), and count.

Glob is a path search: it matches file names and paths against a glob pattern and returns the matching paths, sorted by modification time. Use it when you know a naming convention but not the location, for example **/*.test.tsx to find every React test file, or src/**/*.ts to enumerate a package's TypeScript sources.

The one-line rule: if you are looking for text that lives inside files, use Grep; if you are looking for files by their name or extension, use Glob. Confusing the two is a classic distractor. Glob will never find a function body, and Grep is the wrong tool for 'list all the test files.'

Grep  pattern='def process_refund'  output_mode='content'  -n=true   # who defines / calls it
Glob  pattern='**/*.test.tsx'                                        # every test file

Read loads a full file and returns it with line numbers; you can page large files with an offset and a limit. Write creates a file or overwrites an existing one wholesale. Edit performs an exact string replacement: you give it old_string (the text to find) and new_string (the replacement).

Two hard requirements make Edit reliable. First, you must Read a file before you Edit or Write an existing one; the tools refuse to modify a file the session has not seen. Second, old_string must match exactly one location in the file. If the anchor text appears more than once, Edit fails rather than guessing which occurrence you meant. You resolve this by adding enough surrounding lines to old_string to make it unique, or by setting replace_all when you truly intend to change every occurrence.

Edit  old_string='const timeout = 30'  new_string='const timeout = 60'
# error: 'timeout = 30' appears 3 times -> not a unique match

Use Edit for surgical changes and Write when you are replacing most of a file or generating it fresh. Write is heavier: it rewrites the entire file, so it costs more tokens and can clobber other changes if used carelessly.

When Edit reports that its old_string is not unique and you cannot easily disambiguate it, the reliable fallback is to Read the whole file, construct the corrected contents, and Write the file back. This sidesteps the uniqueness constraint entirely because Write does not depend on matching an anchor.

This is the specific pattern the blueprint calls out. It is safer than the tempting alternative of replace_all, which changes every occurrence of the anchor, often not what you want when only one of several identical lines should change. Read+Write lets you place the change exactly where it belongs by rewriting the surrounding context deliberately.

The trade-off is cost and blast radius: Read+Write moves the entire file through context and rewrites all of it, so prefer a more specific Edit (with extra surrounding lines to make the anchor unique) when that is feasible, and reserve full Read+Write for cases where the anchor genuinely cannot be made unique or the change is extensive.

When you land in an unfamiliar codebase, do not Read every file to 'understand it first.' That floods the context window with mostly irrelevant content, triggers lost-in-the-middle omissions, and degrades answer quality over a long session. Build understanding incrementally instead.

Start with Grep to locate entry points: the route handler, the CLI command, the exported function named in the task. From a hit, Read just that file, note what it imports, then Grep or Read the next hop in the chain. You follow imports and call sites outward, pulling in only the files that are actually on the path you care about.

This mirrors the domain-5 context-management guidance: keep the working set small and relevant. A good exploration transcript is a tight alternating rhythm of narrow Grep searches and targeted Reads, not a wall of full-file dumps at the start.

A function is often re-exported through wrapper or 'barrel' modules, for example an index.ts that does export { doThing } from './impl', sometimes renaming it. A single Grep for the original name will miss call sites that import it under a different name or through the barrel.

The reliable technique is two-phase: first identify all the exported names the symbol travels under (grep the export and re-export statements to see how it is surfaced), then Grep for each of those names across the codebase to find every caller. This catches aliased and re-exported usages that a single-name search overlooks.

Grep  pattern='export .* processRefund'   # find how it is exported / re-exported / aliased
Grep  pattern='processRefund|refundOrder' # then search every name it is used under

This is the built-in-tool version of 'find all callers': the accuracy of the trace depends on enumerating the names first, not on one lucky search string.

Bash executes shell commands in a persistent working directory: running the test suite, building, git operations, invoking scripts, moving files. It is the tool for doing things to the system, and for many tasks it is essential.

What it should not be is a stand-in for the dedicated tools. Reaching for grep -R, find, cat, head, tail, or sed in Bash is discouraged when Grep, Glob, and Read exist. The dedicated tools are faster (Grep is ripgrep under the hood), return results in a structure the model handles well (line numbers, path lists, context), respect ignore rules, and integrate with the permission system. Shelling out for search also produces raw, unpaginated output that bloats context.

So the split is clean: use Grep / Glob / Read to inspect the codebase, and Bash to run the commands that act on it. A distractor that 'searches the codebase' via bash grep -r is choosing the wrong tool even though it would technically work.