The thing about the separate model call is what changes everything — and I don't think most people using slash compact even realize it's happening.
That's where Daniel's question lands, actually. He sent us a prompt about exactly this layer — the one above the compaction mechanics we dug into before. Let me read what he wrote.
Go.
He says — a previous episode covered how conversation compaction actually works under the hood in Claude Code, and this one is about the layer above that. Prompting it. In Claude Code you don't just run slash compact and accept whatever you get — you can pass it an instruction alongside it, which means you're steering what survives the summarization. That turns compaction from a lossy default into a directed operation. You could compact into a handover brief for a different AI agent that's picking up the work. You could compact into a task list. But he suspects there are considerably cleverer things you can do than either of those. He wants us to start by pinning down the vocabulary — is there an actual term of art for these instructions, what are we even calling this. Mechanically it's a prompt being concatenated onto whatever the built-in compaction prompt already is, so is there established language for that pattern. Then the real question — what are the genuinely clever and creative ways to use this, what prompting patterns produce more effective context compaction workflows.
That's three questions wrapped in one, and they stack exactly right — what do we call it, how does the mechanics shape what we write, and what can we actually do with it.
So let's start with the vocabulary. What is the term of art for the thing you type after slash compact?
There isn't one.
Nothing?
Nothing widely adopted. The closest you'll find in the documentation is "instruction" — which is accurate but so generic it doesn't distinguish this from anything else. In the broader LLM ecosystem, the pattern of concatenating a user prompt onto a built-in system prompt is sometimes called prompt concatenation or prompt chaining, but those are umbrella terms, not specific to compaction. If you search for what people actually call this in practice, you'll find phrases like "compaction instructions" or "compaction hints." The practice is ahead of the vocabulary.
Which is a problem, because without a shared term you can't build shared patterns. You can't say "here's my compaction directive for debugging sessions" and have everyone know what that means.
Right. I've been calling them compaction directives in my own notes, and that's probably the most functional term right now — it captures that you're directing the summarizer rather than just hinting at it. Some people say summarization steering prompts, which is more precise mechanically but a mouthful. Neither is canonical. The documentation from Anthropic just calls it an instruction, and the slash compact command accepts it as an optional argument.
So we're in the naming-things phase of the practice. That's actually exciting — it means the patterns haven't ossified yet.
It does, and the vocabulary gap tells you something about how fast this feature went from "utility function" to "something you can creatively steer." The instruction argument was probably added as a convenience — "oh, let people add a note about what to emphasize" — and then people immediately started using it as a full prompt engineering surface. The community outran the naming.
Alright, so let's call them compaction directives for this conversation. Mechanically — what's actually happening when you pass one?
This is where it gets interesting, and where the misconception sits. Most people assume the slash compact instruction is read by the main conversation model — the same Claude instance that's been helping you code — and that it just influences the summary somehow. That's wrong. Compaction uses a separate model call for summarization. The conversation gets handed off to a dedicated summarization invocation, and your directive is concatenated onto the built-in compaction prompt that that invocation receives.
So it's not your coding partner reading your note. It's a different instance entirely, whose only job is to produce a compressed version of the conversation.
And that changes how you should write these things. When you write a note to a human collaborator — "hey, make sure to keep the part about the database migration" — you're relying on shared context, shared understanding of what matters. The summarization model doesn't have that. It has the conversation transcript, the built-in compaction prompt telling it how to summarize, and your directive appended to that. It's reading your words as literal instructions about what to preserve and how to structure the output.
So the failure mode is writing a compaction directive like you're texting a colleague, when you should be writing it like you're prompting a model.
That's the shift. A vague directive like "summarize this well" or "keep the important parts" is almost worse than nothing — you're adding tokens without adding signal. The summarizer already has a built-in prompt telling it to produce a good summary. What you need to add is the specific, structured guidance about what "good" means for this particular conversation at this particular moment.
Give me a concrete example.
Take a debugging session that's been running for an hour. You've tried seven things, five of them were dead ends, two got you closer. A human-to-human handover note might say "tried a bunch of stuff, the database connection pooling seems to be the issue, maybe look at the connection timeout settings." That's fine for a human who can ask follow-up questions. For a summarization model, you want something more like — "Preserve all file paths and function names mentioned. Preserve the current debugging hypothesis about connection pooling. Preserve the two successful diagnostic steps. Discard all five dead-end attempts and their full error traces. Output as a structured summary with sections: Current Hypothesis, Evidence For, Evidence Against, Next Steps."
The difference is specificity and structure. You're telling the summarizer what to keep, what to discard, and what shape the output should take.
And the shape matters as much as the content. The built-in compaction prompt is good at producing a general summary. It's not good at guessing what structure will be most useful for your next session. That's where your directive does the real work — you're not just choosing what survives, you're choosing the format it survives in.
Which brings us to Daniel's real question. What are the clever patterns beyond handover briefs and task lists?
Let me lay out four that I've seen work consistently. The first is compaction as reframing. Instead of summarizing the conversation as a transcript — "first we did this, then we did that" — you instruct the summarizer to reframe the entire conversation through a specific lens. "Summarize this as a series of decisions made and their rationale, not as a chronological transcript." The output isn't a compressed history. It's a decision log with reasoning attached.
So the next session doesn't start with "what were we doing," it starts with "here's what we decided and why." The code you wrote is in the repo. The decisions about why you wrote it that way — those live in the conversation and get lost if you don't explicitly preserve them.
Second pattern — compaction as task extraction. You tell the summarizer to output a prioritized task list with dependencies — effectively turning the meandering conversation into a project plan. "Extract all mentioned tasks, bugs, and features. Group by dependency. Prioritize. Output as a numbered list with status indicators." What you get back is a clean work queue that the next session can start executing immediately.
And the difference between this and just keeping a task list yourself is that the summarizer is reading the whole conversation and catching things you mentioned in passing. "Oh right, we should also update the tests" — you said that at minute twelve and forgot about it, but the summarizer caught it.
That's exactly the value. The summarization model has access to the full conversation in a way that your working memory doesn't. It'll surface the thing you muttered under your breath and never wrote down.
Third pattern.
Compaction as knowledge distillation. This one's my favorite. You instruct the summarizer to extract reusable patterns, gotchas, and lessons learned — not the narrative of what happened, but the wisdom embedded in what happened. "Summarize this conversation as a set of reusable patterns, pitfalls encountered, and solutions discovered. Format each as a named pattern with a one-line description." The next session starts with a knowledge base, not a history lesson.
So you're turning the conversation into a miniature version of those "lessons learned" documents that teams are supposed to write after projects and never actually do.
And because the cost is near zero — it's one additional sentence in your slash compact command — you actually do it. Every session becomes a learning artifact. Over time, if you're saving these somewhere, you build up a personal library of patterns from your own work.
Fourth pattern?
Compaction as perspective shift. This is the most creative one. You compact the conversation from the perspective of a different role. "Summarize this conversation as a security review" or "Summarize this as a code reviewer would — flagging concerns, noting inconsistencies, highlighting what needs testing." The summarizer doesn't just compress the conversation, it reinterprets it through a different lens, and the output primes the next session to operate in that mode.
So you're using compaction not just to preserve context, but to change the mode of the next session.
That's the meta-pattern. All four of these work because your directive is read by the summarization model — you're shaping the structure and framing of what survives, not just the content. When you compact into a security review, the next session starts by reading a security review. That primes the model to think about security from the first prompt. You've used the compaction boundary as a mode-switching point.
That's actually elegant. The moment of context loss becomes the moment of context reframing.
Yes. The thing that's normally a weakness — "oh no, we're losing the full conversation" — becomes a feature because you get to choose what the compressed version looks like. The compaction event is a forced reflection point. You have to decide what matters. Most people treat that as an inconvenience. These patterns treat it as an opportunity.
Let's get concrete about what makes a compaction directive actually work. You said earlier that the separate model call changes how you write these. Walk me through the implications.
First implication — be explicit about what to discard, not just what to keep. The summarizer's default instinct is to preserve everything that seems relevant. If you've spent forty minutes on a debugging dead end, the summarizer might preserve parts of it because it involved real work and real code. But you don't want that in your compressed context. You need to say "discard all dead-end debugging attempts" explicitly. The summarizer doesn't know it was a dead end unless you tell it.
Second implication?
Specify the output format. The built-in prompt produces a certain kind of summary — it's conversational, it preserves the flow. If you want a structured output — bullet points, sections, a decision table — you have to ask for it. And structured outputs are almost always more useful for the next session than prose summaries, because they're scannable. The next session's model can find what it needs faster.
So "output as a markdown document with sections for Decisions, Open Questions, and Next Steps" beats "summarize this conversation."
By a lot. The format request does double duty — it tells the summarizer what to produce, and it implicitly tells it what to look for in the conversation. If you ask for a Decisions section, the summarizer goes hunting for decisions. The format shapes the extraction.
Third implication?
Write for a model that has no memory of the conversation. Your directive is the only guidance the summarizer gets beyond the built-in prompt. It doesn't know that you care about the database schema more than the UI tweaks. It doesn't know that this session is about to be handed off to a different developer. All of that context has to be in the directive.
So "I'm handing this off to a backend developer who's never seen this codebase — preserve all schema details, API contracts, and environment setup notes" is a directive that actually does work. The summarizer now knows who the audience is and what they need.
And that's not something you'd think to include if you were writing a note to yourself. The instinct is "summarize this for me." But the real power comes from "summarize this for the next session, which will be in a different mode with different needs."
I want to push on something. You said these patterns work consistently. How do you know? What does "work" mean here?
Fair question. I mean the output is actually useful as the starting context for the next session — the model picks up the thread quickly, doesn't re-ask questions that were already resolved, operates in the right mode from the first prompt. The structured outputs in particular reduce what I'd call the "re-orientation cost" — the number of turns it takes for the next session to become productive.
And you've measured this?
Not quantitatively. This is observational — my own use and patterns I've seen from other heavy Claude Code users. The re-orientation cost with a good compaction directive is maybe one or two turns. Without one, it can be five or ten turns of the model asking "what are we working on" and you re-explaining things you already explained.
That's a real productivity difference. Ten turns of re-orientation per session adds up fast.
Especially if you're compacting multiple times in a long session. Which you should be — compaction isn't a one-time thing at the end. You compact when context is getting full, which might happen three or four times in a long coding session. Each compaction is an opportunity to reframe.
So you might use different directives at different compaction points. Early in a session, you compact into a task list because you're still figuring out what needs doing. Mid-session, you compact into a decision log because you've made architectural choices. Late in the session, you compact into a handover brief because you're about to stop working.
That's exactly the workflow. The directive should match where you are in the session's lifecycle. The mistake is using the same directive every time — "summarize this conversation" — when what you need from the summary changes as the work changes.
Let's talk about building a library of these. Daniel mentioned reusable patterns, and you hinted at it earlier — having a set of directives ready for common situations.
This is where the practice matures. Instead of writing a directive from scratch every time, you build up a small collection — maybe five or six — that cover your common scenarios. A debugging directive, a refactoring directive, a handoff directive, a review-prep directive. You keep them in a note or a project file, and you copy-paste the relevant one when you run slash compact.
What would a debugging directive look like, fully written out?
Something like — "Preserve the current bug description and reproduction steps. Preserve all hypotheses tested and their results. Preserve the current best hypothesis and the evidence for it. Discard all dead-end debugging attempts and their full output. Discard all conversational filler. Output as: Bug Summary, Hypotheses Tested with Results, Current Best Hypothesis, Next Diagnostic Steps, Files Modified."
That's specific enough that I could copy it and use it right now. Which I think is the test for whether a pattern is actually useful.
And notice what it's doing — it's not just saying what to keep. It's giving the summarizer a structure that makes the output immediately actionable. The next session reads "Bug Summary" and knows what's broken. It reads "Current Best Hypothesis" and knows where to focus. It reads "Next Diagnostic Steps" and knows what to do first. Zero re-orientation cost.
What about a refactoring directive?
"Summarize this conversation as a set of architectural decisions with rationale. For each decision, capture what was changed, why it was changed, what alternatives were considered, and what the implications are for other parts of the codebase. Discard implementation details that are now reflected in the code. Output as a numbered list of decisions with rationale."
The "discard implementation details that are now reflected in the code" is smart. You don't need the summary to tell you what the code already tells you.
That's a general principle for compaction directives — don't preserve what's already in the repo. The code is the code. The summary should preserve what's not in the code — the reasoning, the alternatives, the context, the gotchas.
So the directive is essentially saying "the code tells you what, tell me why."
The conversation contains the why. The repo contains the what. Compaction should preserve the why and let the what speak for itself.
You mentioned a review-prep directive. What's that look like?
"Summarize this conversation as a code review. Flag all decisions that affect security, performance, or data integrity. Note any TODO comments or deferred work. Highlight areas that need testing. Identify any assumptions made that should be verified. Output as a review checklist organized by risk level."
And this goes to your earlier point about perspective shift — the next session starts by reading a review checklist, so it's primed to think like a reviewer.
And that's powerful. One of the hardest things in software development is switching modes — going from "building things" to "reviewing things." Your brain resists it. But if the context you're reading is already in review mode, the switch happens naturally. The compaction directive did the mode-switching work for you.
I want to circle back to something. You said the vocabulary gap is a sign the practice is ahead of the language. But it's also a problem for adoption. If someone doesn't know these patterns exist, they won't go looking for them. They'll just run slash compact with no instruction and accept whatever they get.
That's the discoverability problem. The slash compact command works fine with no arguments. It produces a reasonable summary. Most users will never realize they can steer it because the feature doesn't advertise itself. You have to either read the documentation carefully or stumble across someone talking about it.
Which is why episodes like this matter. The patterns spread through community knowledge rather than through the tool's interface.
And that's actually fine for an emerging practice. The people who need these patterns are the heavy users — the ones compacting multiple times per session, the ones handing off context between sessions that span days. Casual users don't need compaction directives. Power users do, and power users find each other.
Alright, let's pull back to the broader picture. The -pattern you described — using the compaction boundary as a mode-switching point — that seems like it extends beyond Claude Code.
It absolutely does. Any tool that does context summarization could benefit from user-directed compaction. Right now, most AI coding tools either have opaque compaction or no compaction at all. As the ecosystem matures, I'd expect to see compaction directives become a standard feature — and the patterns we're developing now will become the defaults.
Because the problem is universal. Long conversations exceed context windows. Something has to be lost. The only question is whether you get to choose what's lost and how what remains is structured.
Right now, with most tools, you don't get to choose. The summarizer guesses. Sometimes it guesses well. Often it guesses wrong — it preserves the wrong details, drops the crucial context, formats the output in a way that's hard to re-enter. Compaction directives are the difference between "hope the summarizer does a good job" and "tell the summarizer exactly what you need."
There's a trust element here too. If you've been burned by bad compaction — you lost important context and had to redo work — you're going to be reluctant to compact at all. You'll push the context window to its limit and then start a new session from scratch. That's worse.
The reluctance is real. I've talked to developers who avoid compaction entirely because they don't trust it. They'd rather work in an increasingly sluggish session than risk losing something important. Compaction directives solve that trust problem — not perfectly, but significantly. When you've told the summarizer exactly what to preserve, you can be reasonably confident it preserved it.
You can verify. After compaction, you can scan the summary and check that your key points survived. If you gave a structured directive, the structure makes verification easy — "are my three hypotheses there, yes, good."
The structured output request is also a verification aid. If you asked for sections and got sections, you can check each section. If you asked for a decision log and got a decision log, you can count the decisions and see if any are missing.
We've covered the vocabulary gap, the mechanics, the four patterns, and the practical guidance. What's the one thing you'd tell someone to do differently starting tomorrow?
Write your next compaction directive as if you're prompting a summarization model, not leaving a note for a human. Be explicit about what to keep, what to discard, and what format to output. And if you're not sure where to start, pick one of the four patterns — reframing, task extraction, knowledge distillation, or perspective shift — and try it with a session you're about to compact.
The discard instruction is the part most people will miss. It feels unnatural to tell a tool "ignore this thing I spent an hour on." But that hour is already spent. The only question is whether the summary carries its weight or drags it forward.
That's a good way to frame it. The dead ends served their purpose — they ruled things out. They don't need to live on in the compressed context. Your future self doesn't need to re-read the error trace from the thing that didn't work.
Unless the dead end contains a lesson you might need. That's where knowledge distillation comes in — you're not preserving the dead end, you're extracting the lesson from it.
"Discard the debugging attempts, but preserve the insight that the authentication middleware runs before the rate limiter." That's the kind of thing that's worth keeping — the thing you learned, not the process of learning it.
The cutting-room floor detail I keep coming back to is this — the built-in compaction prompt is itself a carefully engineered piece of prompt engineering. Anthropic designed it to produce good general-purpose summaries. When you concatenate your directive onto it, you're not replacing their work, you're extending it. The art is in knowing what to add, not in trying to do the whole thing yourself.
That's the right instinct. The built-in prompt handles the heavy lifting — it knows how to compress a conversation while preserving coherence. Your directive handles the customization — it tells the compressor what "coherence" means for your specific needs. You're not building a summarizer from scratch. You're steering one that already works.
That steering is what turns compaction from a necessary evil into a creative act. You're not just managing context. You're curating it.
Curating is exactly the word. A museum doesn't display everything in its collection. It chooses what to show and how to arrange it. Compaction directives let you be the curator of your own conversation history.
Which leaves us with an open question. As these directives get more sophisticated — as people build libraries of them, share them, iterate on them — do we need a dedicated syntax or format? Or is natural language enough?
I think natural language is enough for now, and probably for a while. The directives we've been describing are just prompts. They work because language models are good at understanding prompts. Adding a formal syntax would make them harder to write without making them much more effective. But I could see a future where compaction directives become a kind of configuration — maybe a dotfile in your project that specifies default compaction behavior for different situations.
A slash compact config file. That's actually interesting — you define your debugging directive once, and slash compact knows to use it when you're in a session that looks like debugging.
Or you define multiple profiles and invoke them by name. Slash compact with the review profile. Slash compact with the handoff profile. The tool reads your config and concatenates the right directive.
Someone's going to build that. If not in Claude Code itself, then as a wrapper or a plugin.
Almost certainly. The pattern is too useful to stay manual forever.
Alright. If you've built a compaction directive that does something clever — something we didn't cover here — send it in. We might do a follow-up episode on community patterns. The email is show at my weird prompts dot com.
If you're just getting started with this, try one directive this week. Pick the pattern that matches your workflow — reframing, task extraction, knowledge distillation, or perspective shift — and run it on your next compaction. See if the next session starts faster.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. We'll be back soon.
See you then.
