Compact instructions: tell /compact what to keep
Left alone, compaction keeps what it judges important, which reliably means the conclusions and not the reasoning. You can tell it otherwise, in one argument or in a hook that never forgets to.
The one-off version
/compact takes an argument, and the text you pass is added to the prompt that writes the summary, under a heading called Compact Instructions. The same thing is available to the SDK, where the session compact call takes an instructions string or nothing at all.
> /compact keep the three pooler configs we rejected and why each one failed. drop the file listings.
Be specific about what to drop as well as what to keep. A summary has a budget, and "keep everything about X" without "drop Y" spends that budget on the same material it would have kept anyway.
What is worth naming
| Rejected approaches, with reasons | The first casualty every time. Six attempts become "several approaches were attempted", which is not enough detail to stop the seventh from repeating the second. |
| Constraints stated once, early | A licensing rule or a version pin you mentioned in the first ten minutes is the most likely thing to quietly stop being true. |
| The exact failing command | Summaries paraphrase commands into descriptions of commands, and a paraphrased command cannot be re-run. |
| What to drop | Directory listings, file contents you have already edited, and long test output. Naming them is what makes room for the rest. |
The hook, for when you forget
You will forget, because compaction arrives during the part of a session where you are concentrating on something else. The PreCompact hook runs before every compaction and supplies the instructions for you. Its contract is short:
| Input | JSON on stdin with the compaction details. |
| Exit 0 | Whatever the command printed to stdout is appended as custom compact instructions. |
| Exit 2 | Compaction is blocked. Claude Code reports it and continues uncompacted. |
| Any other exit | stderr goes to you, and compaction proceeds anyway. |
So a hook that echoes four lines of standing instructions gives every compaction in every session the same floor, whether you triggered it or the token count did. There is a matching PostCompact hook that receives the compaction details and the summary, which is the place to record that a boundary happened.
Exit 2 comes with a warning. Blocking compaction does not create context; it leaves a session running against a window it has already outgrown, and the failure that follows is worse than the summary you avoided.
What instructions cannot do
They shape a summary. They do not make one lossless, and no wording gets a long afternoon of debugging through a summary intact — the budget is the budget. They also cannot preserve something nobody wrote down: reasoning you did in your head and typed only the result of is not in the transcript, so it is not in the summary either.
The backstop for both is that the full transcript never went anywhere. Compaction appends a compact_boundary record to the session file and keeps writing to the same file, so the material the summary could not fit is still on disk, in order, a few hundred lines up.
> what were the three pooler configs we rejected? recall_search reads past the boundary and quotes the original exchange, not the summary of it
Write instructions for the summary, and keep an index for everything the summary had to leave out. The two solve different halves of the same problem.
Questions
| Can I tell /compact what to keep? | Yes. Pass the instruction as an argument: /compact keep the rejected approaches and why each failed, drop the file listings. The text is added to the prompt that generates the summary, under a Compact Instructions heading. The SDK equivalent takes an instructions string or nothing. |
| What is the PreCompact hook in Claude Code? | A hook that runs before every conversation compaction, manual or automatic. It receives the compaction details as JSON on stdin. If it exits 0, whatever it printed to stdout is appended as custom compact instructions, so it is the way to apply the same standing instructions to every compaction without remembering to type them. |
| Can a hook stop compaction from happening? | Yes, by exiting 2, and Claude Code then reports that compaction was blocked and continues uncompacted. It is rarely what you want: the session is still over its context window, and the error that follows is worse than the summary you prevented. |
| What should I put in compact instructions? | Name what to keep and what to drop. Worth keeping: approaches you rejected and why, constraints stated once early on, and the exact text of commands rather than descriptions of them. Worth dropping: directory listings, contents of files you have already edited, and long test output. |
| Is there a hook that runs after compaction? | Yes, PostCompact. It receives the compaction details along with the summary, and anything it prints on exit 0 is shown to you. It is the place to log that a boundary happened, or to re-inject context the summary dropped. |
| What if I never run /compact myself? | Auto-compact runs it for you and picks what survives on its own. Shortly before it fires, Claude Code warns that it is about to discard older messages and suggests running /compact first for exactly this reason. The full transcript stays on disk either way. |
More notes
| Compacting conversation: what Claude Code keeps and drops | What auto-compact does to a long session, why the assistant starts contradicting itself afterwards, and how to get the lost detail back instead of retyping it. |
| Context left until auto-compact: what the number counts | The percentage in the status line, what makes it fall, how to move the threshold, and what actually happens to your conversation when it reaches zero. |
| /clear vs /compact in Claude Code | One summarizes the conversation and keeps going. The other starts a fresh one. What each does to the transcript on disk, and which to reach for. |