One Claude Code Tip a Day: Ask What Claude Did Not Read

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The real failure: confident advice from a partial map

Claude Code is very good at sounding complete after reading a few relevant files. That is helpful when you need momentum, but dangerous when the bug crosses a boundary the session has not inspected: a frontend component calling an API client, a server route normalizing data, a feature flag changing behavior in production, or a deploy script rewriting environment variables. The answer may be locally reasonable and globally wrong.

Today’s habit is simple: before you trust a plan or accept a patch, ask Claude Code what it did not read. Not what it read. Not a polished summary. You want the blind spots: files it inferred, runtime paths it skipped, tests it did not run, logs it did not inspect, and assumptions it is carrying into the next edit.

The workflow: make the unread list a gate

Run the normal Claude Code loop first. Give it the task, let it inspect the code, and ask for either a plan or a narrow patch. Then pause and use this prompt:

`Before we continue, list what you did not read or verify. Include: 1) files or folders that might affect this behavior but were not opened, 2) runtime paths you inferred instead of tracing, 3) commands/tests/logs you did not run, 4) assumptions that would change the fix if false. For each item, say whether we should inspect it now or explicitly accept the risk.`

That prompt changes the session from assistant confidence to scope management. Claude has to mark the edge of its map. Sometimes the answer is reassuring: the skipped files are unrelated styles or generated code. Often it exposes the next useful move.

A realistic session

Imagine a team dashboard where saving a user role appears to work, but the role reverts after refresh. Claude Code reads `RoleEditor.tsx`, finds a state update bug, patches it, and the local component test passes. Without an unread-list gate, you might accept the patch because the explanation is clean.

Now ask what it did not read. A good answer might say: `I did not inspect the API route that persists roles, the permissions serializer, or the network payload from the browser. I inferred that the frontend state was the source because the component test reproduced a local mismatch. We should inspect the API client and one saved response before calling the refresh bug fixed.`

That is not a failure; it is the session becoming honest. The next prompt can be precise: `Open the API client and server route for role updates. Do not edit yet. Tell me whether the saved payload and returned role shape match the component state.` Now the workflow follows evidence instead of charisma.

What to inspect after Claude answers

Treat the unread list like a review checklist, but keep it short. First, look for boundary files: API clients, adapters, serializers, route handlers, queue consumers, migrations, and feature flags. Bugs like to hide where data changes shape. Second, look for verification gaps. If Claude only ran a unit test, ask whether the bug requires a browser check, an integration test, or a log from the deployed service. Third, look for assumptions stated as facts. `This hook only runs on mount` is different from `I confirmed this hook only runs on mount in the component lifecycle.`

You do not need to inspect every skipped file. The goal is to decide deliberately. Some risk is acceptable in a small docs edit. Less is acceptable before a billing change, auth fix, or production deploy.

Second-pass correction

When the unread list reveals a gap, make the second pass narrow. Avoid telling Claude to ‘be more thorough,’ which usually invites a broad tour. Give it one edge to verify:

`The unread list says you did not inspect the serializer. Read only the serializer and the failing test. If the serializer explains the refresh behavior, propose the smallest patch. If not, stop and tell me the next evidence source.`

Or, for a frontend bug: `You have not verified the browser path. Use the existing dev command or test harness if available. If you cannot run it here, write the exact manual verification steps and expected DOM/network evidence.`

This second pass is where the habit pays off. Claude either confirms the original patch, tightens it, or discovers that the first theory was only a convenient local fix.

Failure modes

The first failure mode is asking for the unread list after a vague chat answer but before Claude has inspected anything. You will get generic caveats. Ask after it has read files or proposed a patch, when the missing context is concrete.

The second failure mode is accepting a long disclaimer. Push for named files, named commands, and named assumptions. `More tests may be needed` is not useful. `I did not run the Playwright checkout flow that covers the refresh path` is useful.

The third failure mode is turning the habit into bureaucracy. Do not make Claude audit the entire repository for a one-line copy change. Use it when the task crosses boundaries, touches risky behavior, or when the plan sounds too smooth for the evidence shown.

Rule of thumb

Before you trust Claude Code, make it draw the edge of the map. Ask what it did not read, what it inferred, and what remains unverified. Then choose one missing piece to inspect or explicitly accept the risk. Productive Claude Code sessions are not the ones where the model claims certainty fastest; they are the ones where uncertainty is named early enough to steer the next command.