| name | compact-with-memory |
| description | Enhanced /compact that doesn't just summarize — it extracts and persists key decisions, eliminated approaches, new patterns, and current blockers into MEMORY.md before compressing the conversation. Use this skill whenever the user says /compact, "compress context", "compact the conversation", or when the context window is getting full and you want to preserve institutional knowledge from this session. It ensures that after compression, future sessions can reconstruct the reasoning behind current state, not just the state itself. |
compact-with-memory
An enhanced /compact that treats compression as a memory opportunity: before summarizing the conversation, extract what's worth keeping permanently and write it to MEMORY.md.
Why this matters
Claude Code's autoCompact.ts triggers when token usage exceeds effectiveContextWindow - 13,000 tokens. Standard compaction generates a summary and discards the conversation — fast, but lossy. This skill adds a pre-compression pass that distills the session's institutional knowledge into durable memory files, so future sessions don't have to rediscover what this session learned.
Process
Step 1 — Audit the conversation for memory-worthy content
Read back through the current conversation and identify:
- Decisions made — architectural choices, approach selections, tradeoffs accepted ("we went with X over Y because Z")
- Eliminated approaches — things tried and ruled out, with reasons ("tried approach A, failed because B — don't retry")
- Newly discovered patterns — code conventions, project quirks, API behaviors that aren't in any file
- Current blockers — open issues, unresolved questions that will matter next session
- Factual corrections — anything that contradicted prior assumptions or MEMORY.md entries
Skip:
- Implementation details already visible in the code
- Step-by-step narrative of what was done (git log has this)
- Transient state that won't matter next session
Step 2 — Write to MEMORY.md
Check if MEMORY.md exists. If not, create it as a lightweight index (one line per entry, under 150 chars each).
For each item identified in Step 1, decide:
- Index-only: short, universal facts go directly as a pointer line in MEMORY.md
- Topic file: anything with more than 2-3 sentences of detail gets its own file in the memory directory, with a pointer line in MEMORY.md
Memory file format:
---
name: <descriptive name>
description: <one-line summary — what would make this file worth loading?>
type: feedback | project | user | reference
---
<content — for feedback/project types, lead with the rule/fact, then **Why:** and **How to apply:** lines>
MEMORY.md pointer format (one line, under 150 chars):
- [Title](filename.md) — one-line hook describing when this is relevant
Step 3 — Run the actual compact
After writing the memory updates, run the standard /compact command to compress the conversation. The summary generated by compact should reference what was persisted to memory ("Key decisions written to MEMORY.md — see [file] for X").
Step 4 — Confirm
Tell the user:
- How many memory items were written/updated
- Which files were touched
- That compaction completed
What to write vs. skip
Write to memory:
- "We're using optimistic locking here because the DB doesn't support SELECT FOR UPDATE in this version"
- "The auth service always returns 200 even on failure — check
data.success not status code"
- "User prefers small focused PRs over large refactor PRs — confirmed multiple times"
Don't write to memory:
- "Implemented user authentication with JWT" — the code IS the record
- "Fixed bug in login flow" — git commit message has this
- "Read 5 files and summarized them" — noise
Tone
Be selective. One high-quality memory entry beats five generic ones. If you're unsure whether something is worth persisting, ask: "Would a fresh session benefit from knowing this immediately, before reading any code?"
