Claude Code Tool Sequences

In short: A built-in tool sequence is a short, deliberate chain of Claude Code tools where the output of one feeds the next. Many common development tasks, such as finding every caller of a deprecated function and then their test files, are solved by a Grep followed by a Glob rather than any single tool.

Why a Claude Code tool sequence beats a single tool

A Claude Code tool sequence is the recognition that most useful development tasks are compound: they contain two or more questions, and each question maps to a different built-in tool. A single tool answers a single question well, but it stalls the moment the task needs both content search and path matching, or both discovery and inspection. Chaining the tools, letting the result of one decide how you call the next, is how you cover the whole task without forcing one tool to do a job it was never built for.

The composition is what makes the built-in tools powerful. Grep finds where something lives; Glob finds files by name; Read brings a file into context; Edit changes it. None of these is sufficient alone for a task like "remove a deprecated API and fix its tests", but in sequence they walk the task from discovery to change cleanly. Thinking in sequences, not single calls, is the mental shift Task Statement 2.5 rewards.

Built-in tool sequence: A deliberate chain of Claude Code tools where each step's output feeds the next, such as Grep to find callers then Glob to find their tests, used to solve compound development tasks one tool cannot.

The canonical sequence: Grep then Glob

The sequence the exam returns to most often is finding a function's callers and then their tests. Step one is a content question, where is this function called, so it is a Grep for the function name, optionally scoped by language or directory, which returns the source files that use it. Step two is a path question, which test files belong to those sources, so it is a Glob with a pattern built from the filenames Grep just surfaced, such as **/userService*.test.ts.

What makes this a genuine sequence rather than two unrelated searches is that the second call is shaped by the first. You did not know which test pattern to write until Grep told you which source files were involved. That data dependency, output of Grep becoming input to Glob, is the defining feature of a tool sequence and the reason a single tool cannot stand in for it. Grep alone finds callers but not their tests; Glob alone finds tests by guesswork but cannot confirm which sources actually call the function.

Other sequences you will reach for

Grep-then-Glob is the headline, but a handful of other chains cover most day-to-day work. Grep-then-Read is the inspection sequence: find where a symbol appears, then open just those files to understand them, which is the same incremental loop that keeps the context window lean. Glob-then-Read is the by-name variant: list the files that fit a path pattern, then read the relevant ones. And the modification chain extends further still. Grep to find the code, Read to confirm its shape, Edit to change it, and a verification step such as running the tests to prove the change holds.

The common thread is that each step narrows or transforms what the next step receives. You are never running tools in parallel hoping one sticks; you are running them in an order where every call is informed by the last. That ordering is the difference between a coherent workflow and a scattershot set of searches.

Grep→Glob

callers then their tests

Grep→Read

find then inspect

Read→Edit

confirm then change

Letting the data dependency drive the order

The order within a sequence is not arbitrary. It follows the data. You run the call that produces the information the next call needs. Finding tests for a function has to start with the function, because the test pattern depends on which files use it; reversing the order would have you guessing test names before you know the source files. Likewise you Read before you Edit because Edit requires a prior read and you need to see the exact anchor text first. When you find yourself unsure which tool comes first, ask which one produces input the other consumes, and that is your starting step.

This is also where efficiency lives. A well-ordered sequence touches the minimum number of files: Grep narrows to the relevant sources, Glob narrows to their tests, and only then do you Read or Edit. A poorly ordered or single-tool attempt either misses results or over-reads, both of which the exam treats as the wrong answer even when they eventually reach a result.

Grep-then-Glob sequence for callers and their tests

Loading diagram...

Each step's output becomes the next step's input. Grep's filenames shape Glob's pattern.

Applying the sequence

The exam measures whether you can decompose a compound task into the right ordered chain rather than forcing one tool to do everything. The worked example below runs the canonical sequence on a realistic cleanup task.

Worked example

A tech lead asks Claude Code to remove the deprecated calculateTax helper and update every test that exercises it, across a mid-size TypeScript service.

The task has two distinct questions, and the order between them is fixed by the data. The first question is where calculateTax is called, which is content search, so you Grep for calculateTax scoped to TypeScript. Grep returns the source files that import or call it, say invoiceService.ts and checkoutService.ts. You could not have known those filenames in advance, and that is exactly why this step comes first.

Now the second question becomes answerable: which test files belong to those sources. Because you know the source filenames, you can write a Glob pattern shaped by them, such as **/{invoiceService,checkoutService}*.test.ts, plus a **/*tax*.test.ts pass to catch tests named after the feature itself. Glob hands back the test files. A single tool could not have done this: Grep alone would have found the callers but left you guessing at test paths, and Glob alone would have matched test names without confirming which ones actually touch the deprecated helper.

With both the call sites and their tests in hand, you finish with the modification chain. Read the files to see the exact code, Edit the call sites and the test expectations, then run the suite to verify nothing else broke. The whole job is a clean ordered sequence: Grep to discover callers, Glob to discover their tests, Read and Edit to make the change, and a test run to confirm it. Reaching for any one of those tools alone would have left part of the task unsolved.

Common misreadings to avoid

Both traps below come from treating a compound task as if one tool could carry it.

Misconception

Glob can find the tests for a function on its own, since test files are named after what they test.

What's actually true

Glob matches file names, so it can find files that happen to be named after a feature, but it cannot confirm which tests actually call the function. You first Grep for the callers, then Glob for tests shaped by those filenames, a sequence, not a single Glob.

Misconception

If one tool eventually gets the answer, sequencing two tools is just extra work.

What's actually true

A single tool either misses part of a compound task or over-reads to compensate. An ordered sequence touches the minimum files and answers each sub-question with the right tool, which is why Task 2.5 treats the single-tool attempt as the weaker choice.

A small catalogue of common sequences

Beyond the headline Grep-then-Glob, a handful of named sequences cover most development work, and recognising which one a task fits is the quick path to the right answer. The locate-and-inspect sequence is Grep then Read: find where a symbol lives, then open only those files to understand them. The discover-and-open sequence is Glob then Read: list files by a path pattern, then read the relevant ones. The find-and-change sequence is Grep, Read, Edit, then verify: locate the code, confirm its exact shape, change it with a unique anchor, and run a check to prove the change holds.

What unifies the catalogue is that the first tool always reduces the problem before the second tool acts on the smaller set. You never run the expensive step, a Read or an Edit, across the whole repository; you run it only against what a cheap search has already proven relevant. Memorising the catalogue is less important than internalising that shape, because once you see a task as discover-then-act you will reconstruct the right pair without recalling a list.

The cost of the wrong order or a lone tool

It is worth being precise about why a single tool or a mis-ordered sequence is treated as the weaker answer even when it eventually works. A lone tool on a compound task either drops a sub-question, where Grep finds the callers but never their tests, or it compensates by over-reading, pulling whole files into context to make up for a search it skipped. Both outcomes cost something the exam cares about: completeness in the first case, context budget in the second.

A mis-ordered sequence fails differently. Running the second call before the first has produced its input means guessing at a pattern you could have known, which either misses results or forces a broad, wasteful search. Find the tests before you know which sources call the function and you are matching on hope. The fix is always the same diagnostic: identify which step produces information the other step consumes, and put the producer first. Reading the order off the data dependency also makes your answer defensible under exam scrutiny, because when two options use the same tools in opposite orders you do not need intuition, you ask which call needs the other call output and the order is forced.

The same search tools as a managed agent toolset

The Grep and Glob you sequence inside Claude Code are not unique to the CLI; the Claude Developer Platform surfaces the same built-in search capability to managed agents through its agent toolset. There the tools carry lowercase names, grep for regex content search and glob for fast file-pattern matching, and both are enabled by default once the agent toolset is included in your configuration. You turn the full built-in toolset on with the agent_toolset_20260401 identifier rather than declaring each search tool by hand.

For an architect this closes the loop between the interactive Claude Code experience and a programmatic agent you build on the API. The sequencing instinct is identical: glob returns matching file paths, grep returns matches with their locations, and you chain them the same way, narrowing by path before searching content or searching content before reading. What changes is only the surface. Knowing that the built-in search tools exist as a named, default-on managed toolset, rather than something you must hand-roll, is the kind of platform detail Task Statement 2.5 expects an architect to recognise.

How this shows up on the exam

Task Statement 2.5 sits inside Scenario 4, Developer Productivity with Claude, and this knowledge point is where it tests workflow design rather than single-tool recall. A question describes a compound task, find callers and their tests, locate a config and the code that loads it, and offers options that range from a single tool to various tool orderings. The strong answer names the right sequence and gets the order right, because the order follows the data dependency. Distractors offer a single tool that quietly drops half the task, or the correct tools in an order that asks the second call to run before the information it needs exists.

Check your understanding

A developer needs to find every caller of the deprecated parseLegacyDate function and then locate the test files for those callers, in one Claude Code session. Which sequence is correct?

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

Anthropic

Claude Code best practices | Code w/ Claude

Why watch: Anthropic's official Code w/ Claude talk demonstrates chaining built-in tools (search for callers, then locate related files/tests) as a deliberate multi-step workflow.

References & primary sources

Adaptive study

Master this concept with Archie

Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.

Start studying

Claude Code Tool Sequence: Combining Grep and Glob for Common Tasks