Claude Code memory and context: explain less between tasks

Choose the container before adding more context.

When you explain the same project twice, adding another paragraph to an instruction file feels productive. Sometimes it is. But a rule for every change and an exception for one endpoint have different lifetimes. Mixing them makes it harder to tell which background belongs in the next task.

Anthropic documents persistent instruction files and auto memory as complementary mechanisms. Instruction files contain guidance you maintain; auto memory holds notes Claude records. Their loading and scope depend on the current tool configuration. They are context for the model, not a guarantee that a requirement will be followed. The official memory documentation is the source for current behavior.

Before introducing another tool, inspect those native facilities. The workflow below is a method for organizing the information you already have. It does not require Shifu.

Sort one real task into four groups.

Use a fictional task: add retry support to order creation. An earlier design says the same request ID must return the original order. An incident says acceptance can succeed even when the response is lost. These two facts determine what the new work must preserve.

Write the four groups separately. If a fact appears in more than one place, decide who maintains the authoritative version rather than duplicating increasingly different summaries.

Check what is available before asking for implementation.

Open the applicable instruction files and inspect the tool’s current memory/context view. Confirm the relevant file loaded; do not infer that from its existence on disk. Check whether a parent-directory rule or a local instruction changes the guidance. If the tool’s behavior differs from your expectation, use its current documentation before adding workarounds.

Then inspect the implementation. Does a request ID already exist? Where is acceptance committed? Which test captures a lost response? Historical reasoning tells you what to look for, while current code tells you what exists today. An old decision alone cannot establish either.

The smallest useful prompt states the task, the applicable constraint, the evidence, and the uncertainty. It should let the agent point to a missing contract instead of quietly making one up.

Task: add retries to order creation.
Preserve: one request ID identifies one accepted creation.
Evidence: link the design decision and lost-response incident.
Current state: identify acceptance and persistence boundaries.
Unknown: policy for the same ID with a different body.
Before editing: propose the plan and checks; flag missing evidence.

Keep the brief current as the work changes.

Attach dates and applicability to historical decisions. A retry rule might apply only to one API version or one caller. If a newer accepted decision changes that scope, include it and identify what it replaces. Avoid presenting a proposal as the current contract.

After the task, promote only durable lessons. A newly verified test command may belong in stable instructions. The state of an unfinished migration belongs in a dated task record. An unconfirmed explanation belongs in open questions. This small cleanup stops every completed session from becoming another permanent rule.

When a separate context engine helps.

Native instructions are often sufficient when the relevant knowledge is small, stable, and stored with the repository. A separate retrieval step becomes useful when the next task depends on reasoning spread across earlier discussions, incidents, documents, or coding sessions.

That is the job we are building Shifu around: bringing relevant decisions, constraints, and reasoning from supported work sources into the next task. Retrieval still needs an applicability check. A returned statement is not proof that the implementation matches it, and missing results are not proof that no decision exists.

Try it on one change.

Before your next implementation request, spend a short preparation pass classifying the facts into the four groups above. Remove one irrelevant item, attach one missing source, and leave one unknown explicit. Judge the result by whether the plan preserves the relevant behavior and avoids unnecessary reconstruction—not by prompt length alone.

For tool-specific instruction discovery, auto-memory settings, and troubleshooting, use the official documentation linked below; these details can change. The decision table is a working method you can adapt without changing your coding assistant.