Preserve relevant decisions through session compaction

Prepare a task that can be resumed.

The next step after a coding conversation is summarized still needs the accepted requirement, the exception that makes it difficult, and unfinished work. Prepare those while the evidence is available. A short record preserving one pending check can be more useful than an attractive account of progress.

Claude Code’s current documentation describes compaction as summarizing conversation history. It allows a focused compaction request, and explains that some instruction content reloads while other content is summarized or loaded again on demand. That is useful native support, but it does not establish that a particular decision or qualification survived your session. Check the documentation for the tool you actually use.

Try a small ordinary file and existing task records first. Give the resumed assistant the handoff reference and ask it to read it; saving a file does not establish that every future session loads it.

Save what changes the next action.

Keep one active task handoff, linking authoritative sources. Preserve the qualifications that make the next step conditional in the handoff itself, so the next actor knows why to inspect the source.

When you record a result, distinguish a proposed check, a command that started, a completed observation, and a conclusion. A process being launched is not a passing check. An unanswered external action is not a confirmed failure to retry.

Carry a fictional retry change across the boundary.

In this fictional orders task, a retry with the same request ID must recover the original accepted order. A response can be lost after acceptance. The client previously generated a new identifier inside its retry loop; the current patch moves identifier creation outside that loop.

The client test has observed a stable identifier across attempts. Server-side handling of overlapping requests remains uninspected, and the policy for the same ID with a different body is still an owner question. A handoff saying “idempotent retries finished” would erase both limits.

The worked record uses fictional source labels rather than real paths or evidence. Replace them with permitted references in your environment; do not invent a review or test result to make the record complete.

Task handoff — fictional orders example; checked 3 November 2026
Goal: add client retry support; preserve one accepted order per request ID
Accepted decision: retries recover the original order
Reason: a lost response can follow successful acceptance
Source: D12, accepted 14 May 2026; confirm current caller/API scope
Changed: identifier created outside the client retry loop
Observed: client test reused the identifier across two attempts
Pending: inspect server acceptance/recovery and overlapping requests
Unknown: same ID with a different body; ask API contract owner
Next: inspect service overlap behavior before claiming end-to-end completion
Before editing: read current diff and source contract
Stop if: source scope conflicts or a required policy is unresolved
Refresh when: contract, caller, diff, or test evidence changes

Check the resumed account before another edit.

After compaction, ask the assistant to restate the goal, governing decision, exception, completed evidence, and next step from the handoff. Have it name what remains unchecked. Compare that account with the record before editing.

Then inspect the current working state. Files may have changed since the handoff was written. Read the relevant diff and contract; check a running process or uncertain delivery rather than starting a duplicate. Reuse an earlier test result only when it still covers the current change.

For the example, a good resumed plan inspects service overlap handling and asks about conflicting bodies. It does not celebrate a completed idempotency guarantee or repeat the client patch. If the assistant cannot locate the source, keep that gap explicit and obtain the source or owner answer.

If compaction already happened, recover from evidence.

If compaction already happened, start with current files, the request, decision records, inspectable test outputs, and available session history. Rebuild the same fields; label unsupported details unknown.

Ask a focused question when a missing decision blocks the next consequential action. Do not reconstruct an acceptance, an approval, or a passing test from a plausible narrative. A new check can establish current behavior, but it does not prove that an earlier event happened.

Keep durable project rules in the tool’s supported instruction mechanism when appropriate. Keep temporary completion state in the task handoff, where it can be retired after the task.

Try one handoff before adding more machinery.

On one task, compare the saved handoff with the first resumed plan. Check the constraint, exception, and pending work. Record omissions and repair the account before continuing.

A team lead can ask a maintainer to try this on a few comparable tasks using permitted sources. Track preparation effort, corrections needed after resumption, and handoff maintenance time. Keep ordinary review and test requirements. Narrow or stop the practice if its upkeep produces no useful change to the next action.

This checks continuity on those tasks, not perfect retention, accuracy, faster delivery, or fewer defects. The immediate result is an inspectable next step that preserves the work’s limits.