Note on selection
Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively
What you need to know
- Grep searches file contents for patterns; Glob matches file paths by name or extension pattern — content versus path is the dividing line.
- Read and Write handle full-file operations; Edit makes targeted modifications and requires unique anchor text.
- When Edit fails because the anchor text is not unique, fall back to Read followed by Write rather than retrying Edit.
- Build codebase understanding incrementally: Grep to find entry points, then Read to follow imports and trace flows — do not read every file upfront.
- To trace a function through wrapper modules, first identify all exported names, then search for each name across the codebase.
The six the exam tests
These are the six built-in tools the guide names. Claude Code exposes more. Task and WebSearch appear in Domain 1, and Explore in Domain 3 — but selection among these six is what is scored. They are not interchangeable, and the exam tests whether you reach for the right one first.
Grep— search file contents for a pattern: a function name, an error message string, an import statement. This is the tool for "who calls this?" and "where does this message come from?"Glob— match file paths by name or extension pattern. This is the tool for "find every test file", e.g.**/*.test.tsx. Glob answers questions about which files exist; Grep answers questions about what is inside them.Read— load a file's full contents. Use it once you know which file matters.Write— write a whole file.Edit— make a targeted modification by matching a unique string in the file.Bash— run commands: build, test, git, anything the shell can do.
Edit's precondition, and the fallback when it fails
Edit works by unique text matching. If the anchor text appears more than once — or not at all — the edit cannot be applied unambiguously and it fails. The prescribed recovery is Read the full file, then Write it back with the change applied. That path is reliable because it does not depend on locating a unique anchor at all. Recognizing it as the credited fallback — rather than retrying Edit with a slightly different snippet — is a scored skill. Outside the exam you would usually widen the anchor to a unique span first; on the exam, that option is the distractor.30
Explore incrementally, not exhaustively
The intended workflow for an unfamiliar codebase is deliberately incremental: start with Grep to find entry points, then Read to follow imports and trace flows. You do not read every file up front. Reading broadly burns context on code that turns out to be irrelevant, while the Grep-then-Read loop keeps only what the trace actually touches.31
A specific variant is worth memorizing because wrapper modules defeat naive search: to trace how a function is used across re-exporting layers, first identify all exported names, then search for each name across the codebase. A single Grep for the original function name misses every call site that reaches it through an alias. Two passes — enumerate the names, then search each one — is what gives complete coverage.32
Give the learner a cheat-sheet grid: the six built-in tools the guide names are the rows, and the two columns are what the tool operates on and the stem wording that makes it the right choice. Relation labels are the cell values. Reading down the second column is what makes the scored Grep/Glob (content versus path) and Edit/Write (targeted versus whole-file) distinctions decidable from a question stem.
Show that Edit is gated on anchor-text uniqueness, and that the recovery path when it is not unique is Read followed by Write rather than another Edit attempt.
Worked examples
Exploring an unfamiliar legacy service
Scenario 4 · Developer Productivity with ClaudeAn engineer asks the agent how order cancellation works in a service nobody on the team wrote. The wrong instinct is to Read the whole orders/ directory into context.
The incremental path is much cheaper and more accurate: Grep for the handler name or the user-visible error string to find the entry point, Glob when the question is about which files exist rather than what they contain, then Read only the files the trace actually reaches, following imports one hop at a time. Bash covers verification once the flow is understood.
# 1. Find the entry point by searching CONTENTS
Grep "cancelOrder" # function definition and call sites
Grep "Order cannot be canceled" # the user-facing error message
# 2. Enumerate files by PATH pattern when that is the question
Glob "src/orders/**/*.ts"
Glob "**/*.test.tsx" # every test file, by naming pattern
# 3. Read only what the trace touches, following imports one hop at a time
Read src/orders/cancel.ts
Read src/orders/policy/refundWindow.ts
# 4. Verify behavior
Bash "npm test -- orders/cancel"Edit fails on a repeated line, so Read + Write finishes the job
Scenario 4 · Developer Productivity with ClaudeThe agent tries to change a timeout inside one function, but the anchor snippet timeout: 5000 appears in four places in the file. Edit cannot determine which occurrence is meant, so it fails on the non-unique match.
The correct recovery is the documented fallback: Read the full file, apply the change in the intended location, and Write the file back. Repeatedly retrying Edit with slightly different snippets is the tempting wrong move — each attempt is another guess at uniqueness, and it may silently modify the wrong occurrence if a guess happens to match.
Edit src/http/client.ts
old_string: "timeout: 5000"
new_string: "timeout: 15000"
-> FAILED: 4 matches found; old_string must be unique.
Fallback (reliable, no anchor required):
Read src/http/client.ts # load the full contents
Write src/http/client.ts # write back with the one intended changeTracing a function through wrapper modules
Scenario 4 · Developer Productivity with ClaudevalidatePayment is defined in payments/core, re-exported from payments/index.ts as validate, and re-exported again from a legacy compatibility shim as checkPayment. A single Grep for validatePayment finds three call sites and misses a dozen.
The prescribed technique is two-pass: first identify all exported names, then search for each name across the codebase. That is the only way to reach call sites that never mention the original identifier.
# Pass 1: find every name the function is exported under
Grep "export .*validatePayment" # -> also exported as `validate`
Grep "export .*validate" # -> legacy shim re-exports as `checkPayment`
# Pass 2: search the codebase for EACH exported name
Grep "validatePayment"
Grep "\bvalidate\b"
Grep "checkPayment"
# Then Read the files that matter, following imports from each call siteAnti-patterns
- Using Grep to find files by name pattern instead of Glob (or Glob to find code by content instead of Grep) because content search and path matching are different jobs and the wrong tool returns the wrong shape of answer.
- Retrying
Editwith a slightly different snippet after a non-unique match instead of the guide'sReadplusWritefallback because each retry is another guess at uniqueness and may modify the wrong occurrence. (Outside the exam, widening the anchor to a unique span is the ordinary fix.) - Reading every file in a directory upfront instead of using Grep to find entry points and then Read to follow imports because it fills context with code the trace never reaches.
- Running a single Grep for the original function name when wrapper modules re-export it under aliases, instead of first identifying all exported names and then searching for each because aliased call sites never mention the original identifier.
How it is examined
- Grep-versus-Glob items hinge on one word in the stem: "contents", "pattern in code", "error message", or "callers" means Grep; "file name", "extension", or a glob pattern like **/*.test.tsx means Glob.
- If a stem says Edit failed because the text was not unique, the credited answer is Read then Write. Distractors add more surrounding context to the anchor, or suggest a regex or line-number edit.
- Codebase-exploration items reward the incremental Grep → Read path and penalize reading everything upfront. For wrapper modules, the two-pass answer (enumerate exported names, then search each) beats any single-search option.
References — 3 sources
- Tools reference Anthropic The authoritative `Edit` contract, which names the two remedies Claude Code actually uses for a non-unique `old_string`: a longer string with surrounding context, or `replace_all: true`. The guide credits `Read` plus `Write` instead, and treats widening the anchor as a distractor.
- Common workflows Anthropic The step-by-step walkthrough of exploring an unfamiliar codebase — the incremental Grep-then-Read rule shown as an actual session.
- Set up Claude Code in a monorepo or large codebase Anthropic What changes at monorepo scale — code intelligence, sparse worktrees, per-package configuration — which is where the two-pass grep stops being sufficient.
Live product docs — where they differ from the exam guide, answer from the guide. All references
Exam guide, verbatim — what is measured
Knowledge of
- Grep for content search (searching file contents for patterns like function names, error messages, or import statements)
- Glob for file path pattern matching (finding files by name or extension patterns)
- Read/Write for full file operations; Edit for targeted modifications using unique text matching
- When Edit fails due to non-unique text matches, using Read + Write as a fallback for reliable file modifications
Skills in
- Selecting Grep for searching code content across a codebase (e.g., finding all callers of a function, locating error messages)
- Selecting Glob for finding files matching naming patterns (e.g., **/*.test.tsx)
- Using Read to load full file contents followed by Write when Edit cannot find unique anchor text
- Building codebase understanding incrementally: starting with Grep to find entry points, then using Read to follow imports and trace flows, rather than reading all files upfront
- Tracing function usage across wrapper modules by first identifying all exported names, then searching for each name across the codebase