One Claude Code Tip a Day: Use /compact Before the Signal Gets Buried

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

The failure: a good session becomes a noisy transcript

A long Claude Code session can start with excellent discipline and still become hard to trust. Imagine you are fixing a production-only bug in a Next.js dashboard. Claude reads the route handler, finds a suspicious cache header, patches it, and the unit tests pass. Then the staging build fails because an environment variable is missing. Then a Playwright check shows the chart still renders stale data after navigation. After ninety minutes, the transcript contains useful facts, dead theories, temporary patches, logs from three different environments, and five versions of the same plan.

Today's tip is to use `/compact` before that pile buries the signal. `/compact` is not a magic cleanup button. It is a checkpoint. The goal is to preserve the investigation state that should guide the next edit while dropping the conversational debris that makes Claude overfit to old guesses.

Compact when the work changes phase

The best time to run `/compact` is when the session changes phase: from exploration to implementation, from implementation to verification, or from local debugging to deployment. Do not wait until Claude starts forgetting files or mixing errors together. Use compaction when you can still name the useful state clearly.

A practical trigger is this: if your next prompt starts with “remember that earlier thing,” compact first. Another trigger is a messy working tree. Before asking Claude to make a second patch, pause and ask for a checkpoint:

Prompt: `Before I run /compact, summarize the current session as an engineering checkpoint. Include the original task, files read, decisions made, rejected theories, current git diff, commands run, exact failing output, and the next verification command. Separate evidence from assumptions. Keep it short enough to survive compaction.`

Read that checkpoint. If it says “probably fixed” without naming a command, push back. If it lists files Claude never actually opened, push back. A compacted session is only as good as the checkpoint you let into it.

Use /compact like a field notebook

Now run the command:

Command: `/compact`

After compaction, immediately give Claude a narrow continuation prompt instead of asking for a vague “continue”:

Prompt: `Continue from the compacted checkpoint. Start by restating the current proof boundary: what is confirmed, what is still failing, and which command or browser check will prove the next change. Do not edit until you identify the smallest remaining hypothesis.`

This turns `/compact` into a field notebook. The notebook does not include every conversation sentence; it keeps the route map, the observations, and the next test. In a frontend bug, that might mean: `ChartPage.tsx now fetches fresh data on route change`, `staging still shows stale data after back navigation`, `Playwright repro is tests/chart-cache.spec.ts`, `next check is pnpm test:e2e -- chart-cache --headed`. Those lines are more valuable than twenty paragraphs of transcript.

What to inspect after compaction

The first answer after `/compact` deserves inspection. Claude should not behave as if the whole session is still available. It should acknowledge uncertainty and anchor itself to the checkpoint. I like to ask for a three-part recap: confirmed facts, open questions, next verification. If the recap invents facts, stop before editing.

Use prompts like these:

Prompt: `List the facts you are relying on from the compacted context. For each fact, say whether it came from code, logs, tests, browser verification, or an assumption.`

Prompt: `Review the current git diff before making another change. Which lines are experimental? Which lines are part of the intended fix? What should be reverted if the next test fails?`

This is where `/compact` becomes more than context management. It becomes a forcing function for evidence hygiene. You are teaching Claude Code that the next patch must be justified by inspected state, not by momentum from a long conversation.

Failure modes of /compact

The first failure mode is compacting a bad story. If the checkpoint carries a wrong root cause, compaction makes that story feel official. Before running the command, ask Claude to mark assumptions and rejected theories explicitly. A line like `root cause is definitely caching` is dangerous unless the logs and tests prove it.

The second failure mode is compacting too late. When the session has already mixed staging logs, local logs, and CI logs into one blob, the summary may be unreliable. In that case, use `/clear` with a manually curated handoff instead. `/compact` is best when the session is long but still coherent.

The third failure mode is skipping verification after compaction. The compacted session may have lost a detail that matters. Run the next named command, open the page, inspect the DOM, or review the diff before trusting the continuation. Context compression is not correctness. Evidence is correctness.

Rule of thumb

Use `/compact` when the session still contains a useful story but too much noise. Checkpoint the bug, evidence, decisions, diff, and next verification command. After compaction, make Claude restate the proof boundary before it edits. If `/clear` is a clean-room restart, `/compact` is a field notebook: keep the signal, drop the transcript, and make the next patch earn its place in the diff.