Mop first, prompt later

A coding session can begin with one bug and end with a small archive: logs, source files, rejected approaches, tool responses, and decisions scattered across a long conversation. The next request may be short, but it arrives with a lot of baggage.

That is the reason for the mop in the title. Before asking for another change, it helps to look at the working space and decide what still belongs there. Context management is a practical way to keep the next decision connected to the right evidence.

The model works from the context it receives

The current model call operates on the information the application supplies. Claude Code assembles instructions, conversation material, and relevant tool results around the next request. The assistant's apparent continuity comes partly from that supplied context and partly from the application's session and memory features.

It would be too broad to say that the entire product has no memory. The application can save conversations, load project instructions, retrieve notes, and summarize older material. The important question is narrower: what information is available to the model for this particular decision?

collecting fixtures …
loading parser module …
checking sample inputs …
case [12, 8] … passed
case [5] … passed
case [] … failed
reading parser entry …
tracing other callers …
checking cached output …
reviewing test history …
more investigation …

Look at what is taking up space

The active context can include system instructions, project rules, tool descriptions, messages, retrieved files, and returned data. Their sizes vary with the environment and task. A large query result can outweigh several conversational turns, while a concise project rule can be worth its space for the whole session.

Use /context to inspect the current picture rather than relying on a universal overhead estimate. Claude Code can also defer MCP tool definitions through tool search, so connecting a server doesn't always mean loading every schema upfront. The MCP documentation describes that behavior.

Results still matter after discovery. If a query returns thousands of irrelevant records, a model has to work with that response or a summarized version of it. Design calls to retrieve what the task needs: the failing test output, the relevant function, or a limited set of matching records.

Spend space on the next decision

Suppose the current job is fixing an empty-input bug. The constraint about the public API matters. The exact error matters. An unrelated deployment discussion probably doesn't. The useful question is what a fresh conversation would need to reach the next step without repeating the entire investigation.

Start by searching for a symbol, then read the relevant area. Ask a database for the columns and rows that answer the question. Have a helper investigate a bounded hypothesis and return its finding with file locations. These habits control what comes in before there is a reason to compress it.

Keeping context focused doesn't mean withholding necessary detail. If the task spans several modules, those relationships belong in the working information. The aim is relevance, not winning a contest for the fewest tokens.

Capacity and useful attention are different

A larger window allows larger inputs. It doesn't guarantee that every detail will be used equally well. Lost in the Middle studies how retrieval performance can depend on where information appears in a long context, using particular models and tasks.

That is a reason to organize information, not evidence for a universal percentage at which every model becomes unreliable. If an answer misses a constraint, inspect the prompt, source evidence, and task ambiguity too. Occupancy alone cannot diagnose every failure.

Put the active objective and decisive constraints where they are easy to find. Cite relevant source files instead of burying a conclusion inside a wall of output. The same organization helps the human checking the answer.

Project instructions should be easy to carry

CLAUDE.md is useful for stable project conventions: the commands that validate a change, the boundaries of a module, or a rule that would otherwise need repeating. It becomes harder to use when it contains every runbook and historical discussion.

Move task-specific detail into ordinary project documents that can be read when needed. A short index can point at those files. Imported instructions still contribute to the context when loaded; splitting one long file into several imports doesn't automatically remove the reading cost.

Claude Code's memory documentation distinguishes authored instructions from automatic memory and describes how topic files can support a concise index. Keep important decisions recoverable, and inspect what the application actually loads.

Compact when continuing still makes sense

/compact summarizes conversation material so the session can continue with more room. That is useful when the current task still belongs in the same conversation. Summaries can lose detail, so preserve critical facts in source files or a small handoff rather than trusting the summary as the only record.

/compact Keep the parser objective, the public API constraint,
the failing fixture, and the checks already run.

The request guides the summary; it doesn't prove every detail survives. After compaction, check that the objective and constraints remain clear before taking an action that depends on them. Automatic compaction provides continuity too, but reviewing the carried state is still worthwhile.

Know when to resume and when to start fresh

Use /rename to give a session a recognizable purpose and /resume to return to it. Resume is useful when continuing the same thread. It doesn't establish that the repository and external systems still match what the conversation last observed.

For a different task, /clear gives the next conversation a fresh start. A pause between related tasks may be a good point to write down the relevant state. Starting again feels much less expensive when the important facts already have a home.

Carry a handoff instead of the whole transcript

A handoff can be an ordinary project file. It doesn't require a special slash command. Ask the assistant to record the objective, changed files, checks and outcomes, remaining uncertainty, and the next action. Review the result before treating it as the continuation plan.

Make the handoff checkable. Record the command and output behind a passing check, and point to the diff behind a changed file. In the next session, inspect those references and confirm anything that may have moved since they were written.

Recover from a wrong turn

/rewind can return to a checkpoint, with options for conversation and supported code changes. Checkpointing has limits: edits made through shell commands and external side effects aren't generally undone by it. Git and direct verification still matter.

A conversation branch can preserve one direction while exploring another; it doesn't automatically isolate the checkout. When alternatives include editing files, review the working state or use an appropriate worktree. Conversation history and repository state are separate things to manage.

Let an investigation return a finding

Subagents are useful when a search or review can be bounded independently. Give the helper the relevant constraints and ask for evidence with its conclusion. Its investigation still uses tokens, but a concise report can keep the parent's later work focused.

Delegation also needs judgment. A task that depends on many unrecorded decisions may require a better brief before it can be handed over. Separating a conversation doesn't make missing information appear.

Leave the desk ready for the next task

Inspect the active context, narrow incoming results, and keep durable decisions in files. Compact when continuing the same task makes sense; use a short, checked handoff when a fresh conversation is the better next step.

The point is to make the next request easier to answer and the result easier to verify. A clear objective, relevant evidence, and recoverable decisions are the useful things to carry. The rest of the investigation can stay in its notebook.