Your first real task: ask a question about code you did not write

You have a repository you did not write, a ticket that assumes you understand it, and nobody free to ask. This is what Claude Code is best at on day one, and it is not a coding task at all — it is a question. Lesson 1.3 taught you to read what a session is doing; this gives it something worth doing. First thing to unlearn: you do not have to prepare context for a question.

Claude Code reads your project files as needed. You don't have to manually add context. — Quickstart

Nothing you are required to paste, no architecture summary you owe it first. You ask; it reads. Lesson 2.2 covers the cases where handing over a file or an image is still the better move; everything below is about aiming the reading it does on its own.

Where you start the session decides what it can see

Before you type anything you have made one decision — the directory you ran claude in — and it is bigger than it looks:

Where you launch claude determines which files Claude can read and edit without an additional permission grant, which CLAUDE.md files load into context at startup, and which project settings apply. — Work in large codebases

Three things, decided at once, by a cd:

The default is what you would guess — "By default, Claude has access to files in the directory where you launched it" (Permissions) — extendable with --add-dir <path> at launch or /add-dir mid-session. For a first question about an unfamiliar repo, start at the root: you do not yet know which subtree holds the answer. What a session reaches from there is more than the files: the docs list your git state among them — "current branch, uncommitted changes, and recent commit history" (How Claude Code works) — so why is this written this way is often answerable from history rather than from the code.

Ask the question you would ask a senior engineer

There is no technique here. The docs are blunt about it — "No special prompting required: ask questions directly" — and their examples read like a conversation with a colleague, not a search query (Best practices):

How does logging work?
How do I make a new API endpoint?
What does `async move { ... }` do on line 134 of `foo.rs`?
What edge cases does `CustomerOnboardingFlowImpl` handle?

The third names one line of one file; the first a whole subsystem. Both are legitimate — specificity is not a virtue in itself, it is how you spend a smaller budget when you already know where to look. One rewrite is worth learning, though, because it hands over the thing that answers the question:

Same question; the second names the source. The docs call this pointing to sources. It is the cheapest upgrade available to anything you ask.

Broad, then narrow

"Start with broad questions, then narrow down to specific areas" (Common workflows) — and narrow by tracing a path, not by naming another topic:

give me an overview of this codebase
find the files that handle user authentication
how do these authentication files work together?
trace the login process from front-end to database

If that opening line looks like the vagueness the next section warns about — it is, and it is fine: "Vague prompts can be useful when you're exploring and can afford to course-correct" (Best practices). Can afford to is the load-bearing half. Cheap and redirectable in a fresh window; the same vagueness ninety minutes in is the trap below.

The infinite exploration, and the two ways out

The docs name this as a failure pattern, not a style preference:

The infinite exploration. You ask Claude to "investigate" something without scoping it. Claude reads hundreds of files, filling the context. — Best practices

Why it hurts is a separate fact: the window "holds your entire conversation, including every message, every file Claude reads, and every command output", and one exploration "might generate and consume tens of thousands of tokens" (Best practices). Every file read stays. The cost is not the minute you waited — it is that the question you came for now gets asked into a window full of code neither of you needed.

Two documented fixes, and neither is "ask more politely":

Fix: Scope investigations narrowly or use subagents so the exploration doesn't consume your main context. — Best practices

Scope it. Give the question a target — a feature, a file, an execution path, a symbol. "Trace the login process from front-end to database" bounds itself; "look at the auth stuff" does not.

Delegate it. The reading can happen somewhere that is not your window: "Exploring a large codebase fills your context with file reads. Delegate the exploration so only the findings come back" (Common workflows).

use a subagent to investigate how our auth system handles token refresh

The subagent reads in its own window and reports a summary. Level 8 covers defining agents and what they inherit; today it is just the second escape.

What the search tools can and cannot see

An answer is only as good as the search that found it. Lesson 1.3 taught you to read tool-call lines; here is what those names imply about what you are told.

Read the first two rows together, because they disagree, and that disagreement is why "find every place X is used" comes back both too long and too short in one session. Glob sees your dist/, your vendor/, your generated clients; Grep does not. Neither is wrong — they answer different questions, and only you know which one you meant. The cap matters the same way: when 100 files is not all of them, "Claude sees a truncation flag in the result and can narrow the pattern" (Tools reference). Note who that sentence says sees the flag: Claude. So treat a result that stops at exactly 100 files as a count you have not been given, and when a count decides something, ask for the count rather than the list. Grep's count mode prints a per-file count and a total across matching files, and that total covers every match even when the listed entries are truncated — a guarantee that arrived in v2.1.208; before that the total summed the listed entries alone, so a truncated count came back short in the same direction as the list it came from (Tools reference). Learn that as a shape of failure rather than as a version note: "how many, and did anything get cut off" is the form of the question that survives whatever the tool happens to do. PARTIAL view is the quiet row for the same reason — a confident answer about a 4,000-line file can rest entirely on its first page, and the prose need not mention which page it read. Asking which lines it came from does.

Make the answer checkable

An explanation of code you have never read is unfalsifiable by definition: you have nothing to check it against except the confidence it was written with. Fix that in the question, not afterwards.

Have Claude show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot of the result. — Best practices

That is written about verifying work, and it transfers. Because Read returns line numbers, a citable answer is always available — you have to ask for one.

Then spend thirty seconds opening one citation. Not all of them — one. A citation that resolves tells you the reading was real; one that does not tells you far more, far earlier, than re-reading the explanation would.

What you actually do next

Open a repository you have never read. Start claude at its root. Ask for the overview, pick the one thing that surprised you, and trace it — by path, not by topic — until you get a file and a line number. Then open that line yourself. Ask with a target, watch what it reads, demand a claim you can check: that is the loop the rest of the course is built on, and it changes no files.