I wrote "please re-read Skills after Compaction" in CLAUDE.md — why doesn't that work either?
This is exactly what issue #13919 reports: even an explicit "re-read after compaction" instruction written into ~/.claude/CLAUDE.md gets ignored post-compaction. The reason is that compaction itself is fundamentally about clearing and rebuilding context — CLAUDE.md-type startup content genuinely does get reloaded, but Claude reading that instruction doesn't guarantee it will actually go perform the extra action of "re-reading a specific Skill file." Unless you separately configure a hook to automate that action, a line in a documentation file alone doesn't guarantee it actually gets carried out.
Why doesn't the official implementation just automatically re-inject the Skill listing on every Compaction, to save everyone from hitting this?
Anthropic engineer @bcherny's stated reason on issue #74990 is cost: re-sending the entire Skill listing costs a few thousand extra tokens on every compaction, and the original assessment was that preserving the content of already-invoked Skills should be enough. That reasoning holds up fine in a scenario where the user keeps using the same Skill throughout — but it doesn't cover the common case of a user wanting to switch to a different Skill they haven't invoked yet in that conversation. That gap is exactly why this behavior keeps getting reported as a bug rather than accepted as a simple design tradeoff.
Besides manually running /reload-skills, is there a way to avoid triggering this problem in the first place?
If the task itself isn't going to run too long, simply avoiding letting the conversation approach the auto-Compaction threshold (the case in issue #13919 triggered around roughly 55K tokens in the VS Code extension) is the most direct approach — for instance, proactively running /clear to start a new conversation when you clearly move to a new subtask, rather than letting one conversation stretch indefinitely until it gets auto-compacted.
But if the task genuinely needs to run long and depends on the same Skill across multiple steps, rather than trying to avoid compaction altogether, the more practical approach is still configuring a SessionStart hook with its matcher set to "compact" that returns "reloadSkills": true, binding the reload action to the compaction event itself so it fires automatically without you having to remember it each time.
I'm new to Claude Code and have no idea how to configure a hook. Is there a lower-effort way to handle this?
Yes, and it doesn't require touching any config file at all. Just remember one simple pattern: after you see the line "Conversation compacted" in the terminal, if Claude's behavior afterward feels noticeably off (repeating a mistake that was already clearly fixed earlier, for instance), manually run /reload-skills once and see if the problem goes away.
This command makes no changes to your project — it purely re-tells Claude what Skills are available — so the risk is low, and you can treat it as a habitual check right after Compaction. Once you're more comfortable, you can consider setting up the hook to automate it.
Midway through a session, the terminal prints "Conversation compacted" — that's /compact condensing a long conversation into a summary to free up context window space. But if you'd been using a Skill earlier in that conversation, right after Compaction Claude may suddenly behave as if it never had that Skill installed at all — the same mistakes start reappearing, the bad habits the Skill was supposed to prevent come right back. This isn't a bug. It's a deliberate design tradeoff in how compaction works — one that's rarely explained clearly.
The official Context Window documentation is specific about what happens after compaction: content loaded at startup — the System Prompt, CLAUDE.md, memory files, the MCP tool listing — automatically reloads. Claude Code separately re-reads up to the five most recently modified files, and re-injects the content of every Skill you actually invoked before compaction, capped at 5,000 tokens per Skill. The compaction summary itself preserves "your requests and intent, key technical concepts, files examined or modified with important code snippets, errors and how they were fixed, pending tasks, and current work" — what it replaces is the verbatim conversation; full tool outputs and intermediate reasoning are gone.
The detail most easily missed here: the Skill listing itself — the index that originally told Claude "here's what Skills are available right now" — is not re-injected after compaction. The official documentation is direct about this: everything else from startup reloads, but this listing is the one exception — only the content of Skills you actually invoked gets preserved.
GitHub issue #74990 documents this behavior in full: before compaction, Claude correctly reports 27 to 33 available Skills; after compaction, asking Claude what Skills are currently available gets the answer that there's no "Available skills" system-reminder Block to be found — it's not that fewer Skills exist, the entire listing has vanished. Running /reload-skills immediately restores visibility into all 33 Skills, and the command reports back "33 skills available (no changes)." That "no changes" phrase matters — it confirms the Skills themselves were intact the whole time, never deleted or corrupted. The problem is purely whether that listing gets put back into context, nothing else.
Anthropic engineer @bcherny gave the official explanation directly on that issue: this is a deliberate design decision. Re-sending the entire Skill listing costs a few thousand extra tokens on every compaction, and the original reasoning was that preserving the content of Skills already invoked should be enough. The gap this misses: if the user wants to invoke a different Skill next — one that hasn't been used yet in this conversation — Claude has no way of knowing it even exists, because the listing is no longer in context.
Issue #13919 describes a thornier case: in the VS Code extension, once auto-compaction triggers around the ~55K-Token mark, Claude doesn't just forget which Skills are available — it forgets the actual methodology a Skill had taught it, even for Skills already in use. The reporter's example: a Skill that specified "never do ABC (a common mistake)" and required Claude to say "SKILL ACTIVE" at the start of every response. After compaction, Claude stopped saying that line and started making the ABC mistake the Skill explicitly forbade — even when the user had written explicit "re-read the Skill after compaction" instructions into ~/.claude/CLAUDE.md, that instruction itself got ignored post-compaction too. The reporter estimated a task that should have taken about an hour stretched to five or six hours because of this recurring error loop.
The fix documented under issue #74990 is direct: manually run /reload-skills after every compaction event, or configure a SessionStart hook with its matcher set to "compact" that returns "reloadSkills": true, automating the step so you don't have to remember to do it manually every time. If your workflow leans heavily on a handful of Skills, setting up that hook costs far less than repeatedly discovering after the fact that Claude has "forgotten" how to do something.
The clearest signal: Claude's behavior was completely normal before compaction, actively applying whatever a Skill taught, and then right after compaction it suddenly starts making the same category of mistake again — or you directly ask what Skills are currently available and get an answer that's noticeably thinner than before. If that happens, first confirm whether you just went through a /compact or an auto-compaction (you'll see "Conversation compacted" in the terminal), then run /reload-skills once to check whether it restores things. If it does, you've confirmed this is the cause — not a misconfigured Skill.