One Claude Code Tip a Day: Use /clear Before the Context Turns Muddy

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

The failure: the session remembers too much of the wrong story

The most expensive Claude Code sessions are not the ones that start badly. They are the ones that almost work for forty minutes, accumulate three failed theories, and then keep treating those theories as useful context. You ask Claude to fix a flaky checkout test. It tries a timing change, then a selector change, then a mock-data change. The latest patch passes locally once, but the CI log still points at a race between the payment iframe and the order-summary render. At this point, more context is not always better. Sometimes the context has become polluted.

Today's tip is to use `/clear` as a deliberate second-pass tool. Do not think of it as giving up. Think of it as wiping the conversation while keeping the evidence. The goal is to stop Claude Code from dragging stale assumptions, abandoned patches, and half-correct explanations into the next fix.

Before /clear, capture the receipt

Never run `/clear` in a panic. First ask Claude to produce a short receipt of the session that separates evidence from guesses:

Prompt: `Before I clear the session, write a handoff brief. Include: the original bug, files inspected, commands run, exact failing output, patches attempted, what each attempt proved or disproved, current git diff summary, and the next verification command. Mark guesses clearly. Do not propose new edits.`

Then inspect the receipt like you would inspect a pull request. The useful parts are concrete: `pnpm test checkout-race.spec.ts --repeat=20`, `OrderSummary waits for totals but not iframeReady`, `attempted waitForSelector passed locally but failed in CI`, `git diff touches CheckoutPage.tsx and test/fixtures/payment.ts`. The dangerous parts sound confident but uncited: “probably a Playwright issue” or “CI is slower.” Delete or challenge those before carrying the brief forward.

Use /clear to restart from evidence, not vibes

Once you have the receipt, run the command in Claude Code:

Command: `/clear`

Now paste a compact, evidence-first prompt into the fresh session:

Prompt: `We are debugging a flaky checkout test. Here is the handoff brief from the previous session. Treat all guesses as untrusted. Start read-only: inspect the named files and failing output, then state the smallest hypothesis that explains the evidence. Do not edit until you name the verification command that would prove the fix.`

This is the difference between resetting and forgetting. You are not throwing away the work. You are removing the conversational momentum that made Claude prefer its latest theory. In real development, that momentum matters. Models are good at continuing a story; `/clear` lets you change the story back to the code, logs, and tests.

What the second pass should do differently

A strong second pass should feel narrower than the first. Instead of touching selectors, fixtures, and component timing in one sweep, Claude might say: `The evidence only proves that OrderSummary can render before iframeReady. I will inspect CheckoutPage.tsx and paymentIframe.ts, then add a deterministic wait around the readiness signal.` That is a better plan because it names the proof boundary before editing.

After the patch, ask for a contract-style review:

Prompt: `Review the new git diff against the handoff brief. Which previous failed theories did this avoid? Which evidence does the patch address directly? Run or name the exact command that should fail before the fix and pass after it.`

If the answer cannot connect the diff to the original failing output, the reset did not help. You have a fresh session, but not a better investigation. Push it back to evidence: logs, stack traces, screenshots, DOM state, test repeats, or deployment output.

Failure modes of /clear

The first failure mode is clearing too early. If Claude has not inspected the relevant files or run a meaningful command, there is no receipt to preserve. You will only restart with the same vague prompt. Use `/clear` after you have enough evidence to write a useful brief, not before the work has begun.

The second failure mode is pasting the entire old transcript into the new session. That recreates the pollution you were trying to remove. Paste the handoff brief, a small failing excerpt, and the current diff summary. If a detail matters, make it earn a line in the brief.

The third failure mode is using `/clear` to avoid accountability. A reset is not a license to abandon the previous diff. Before clearing, either commit nothing, stash the experiment, or explicitly tell Claude the current working tree state. A clean conversation with a dirty git tree is still a confusing session.

Rule of thumb

Use `/clear` when the conversation has more theories than evidence. Before clearing, make Claude write a receipt. After clearing, restart with that receipt, distrust the guesses, and force the next patch to prove one narrow hypothesis. Claude Code becomes much more useful when you treat context as something to curate, not something to hoard.