context-compressor
Context Compressor
Finite channel (context window) must carry maximum decision-relevant signal. Score fragments by entropy and redundancy, cut or compress accordingly.
Vocabulary
| Info Theory | Context Engineering |
|---|---|
| Channel / Capacity | Context window / window minus system prompt overhead |
| Entropy | Information per token |
| Self-information | How much a fragment reduces agent uncertainty |
| Redundancy | Tokens carrying no new info given other context |
| Lossy compression | Summarize at lower fidelity to save tokens |
| Lossless compression | Reformulate more densely, same facts |
Phase 1 — Budget
Calculate: window - system_prompt - tools - history - output_reserve = available. Compare available vs. candidate context:
| Regime | Ratio | Strategy |
|---|---|---|
| Abundant | >3x | Include all. Stop. |
| Comfortable | 1.5-3x | Cut obvious redundancy |
| Tight | 0.5-1.5x | Active compression |
| Starved | <0.5x | Aggressive triage. Every token justifies itself. |
Phase 2 — Entropy Scoring
Score every candidate fragment on three dimensions:
Self-Information (0-4): 0=derivable from training, 1=agent would guess right, 2=meaningfully reduces uncertainty, 3=changes behavior substantially, 4=without this agent produces wrong output.
Redundancy: Unique / Partial overlap / Mostly redundant / Fully redundant.
Token Efficiency: Dense / Normal / Bloated / Wasteful.
Decision rules:
- Self-Info 0 -> CUT always
- Self-Info 4 -> KEEP always at full fidelity
- Self-Info 1 + Mostly/Fully redundant -> CUT
- Self-Info 2-3 + Bloated -> COMPRESS
- Self-Info 2-3 + Unique + Dense -> KEEP
Output as table: Fragment | Tokens | Self-Info | Redundancy | Efficiency | Action.
Phase 3 — Compress
Lossless (Self-Info 3+, low efficiency): Telegram rewrite, structure extraction, reference elimination, dedup merge.
Lossy (budget Tight/Starved, lossless insufficient): Fidelity reduction (drop rationale, keep rule), scope narrowing (only task-relevant subsection), abstraction raising (drop detail, keep default), probabilistic pruning (cut edge-case-only context, accept risk).
Always log lossy losses:
Fragment: [name] ([before] -> [after] tokens)
Kept: [what survived]
Lost: [what was cut]
Risk: [what agent may get wrong]
Phase 4 — Assemble & Verify
Order by descending self-information (critical first — attention degrades).
Verify:
- Fits budget? Total tokens <= available.
- Agent could complete task with ONLY this context?
- All Self-Info 4 fragments present at full fidelity?
- Any cut fragment that would change agent behavior?
Calibration
- No task = no compression. Always audit against a specific task.
- 80/20. ~20% of context carries ~80% of signal. Find it, keep it full fidelity.
- Compression taxes flexibility. Leave slack for multi-turn needs.
- When in doubt, keep. Wrong output costs more than extra tokens.
- Empirics > theory. Compare agent output with full vs. compressed context when possible.
More from andurilcode/craftwork
deep-document-processor
>
4summarizer
Apply this skill whenever the user asks to summarize, condense, distill, or compress any content — a document, article, meeting notes, conversation, codebase, book, research paper, video transcript, or any other source material. Triggers on phrases like 'summarize this', 'give me the TL;DR', 'condense this', 'what are the key points?', 'distill this down', 'brief me on this', 'what's the gist?', 'BLUF this', 'executive summary', 'compress this for me', or any request to reduce content while preserving its essential value. Also trigger when the user pastes a long text and implicitly wants it shortened, when they share a link and ask 'what does this say?', or when they ask for meeting notes or action items from a transcript. This skill does NOT apply to 'explain X to me' (use topic-explainer) or 'write a summary section for my doc' (use technical-writing). This skill is for when source material exists and needs to be compressed.
3inversion-premortem
Apply inversion and pre-mortem thinking whenever the user asks to evaluate a plan, strategy, architecture, feature, or decision before execution — or when they want to stress-test something that already exists. Triggers on phrases like "is this a good idea?", "what could go wrong?", "review this plan", "should we do this?", "are we missing anything?", "stress-test this", "what are the risks?", or any request to validate a decision or design. Use this skill proactively — if the user is about to commit to something, this skill should be consulted even if they don't ask for it explicitly.
3llms-txt-generator
Generate llms.txt-style context documents — token-budgeted, section-per-concept Markdown optimized for LLM and RAG consumption. Use this skill whenever someone asks to generate an llms.txt, create LLM-friendly documentation, produce a context document for a library or codebase, build a RAG-ready reference, make docs 'agent-readable', create a developer quick-reference, or says anything like 'generate context for X', 'make an llms.txt for this repo', 'create a reference doc for NotebookLM', 'turn these docs into something an LLM can use', 'context document', 'developer cheatsheet from docs'. Also trigger when someone provides a GitHub repo URL and asks for documentation synthesis, or when working inside a codebase and asked to produce a self-contained reference of how it works. This is the context engineer's doc generation tool — it turns sprawling documentation into precise, structured, token-efficient context.
3probabilistic-thinking
Apply probabilistic and Bayesian thinking whenever the user needs to reason under uncertainty, compare risks, prioritize between options, update beliefs based on new evidence, or make decisions without complete information. Triggers on phrases like "what are the odds?", "how likely is this?", "should I be worried about X?", "which risk is bigger?", "does this data change anything?", "is this a signal or noise?", "what's the probability?", "how confident are we?", or any situation where decisions are being made based on incomplete or ambiguous evidence. Also trigger when someone is treating uncertain outcomes as certainties, or when probability language is being used loosely ("probably", "unlikely", "very likely") without quantification. Don't leave uncertainty unexamined.
3context-cartography
Use when designing what goes into an agent's context window — system prompts, tool definitions, retrieval results, or any context artifact assembled before the agent runs. Triggers on "what should I put in the system prompt?", "how do I structure my context?", "the agent loses track of...", "my context window is full", "how do I decide what to include?", "designing a new harness", "the agent ignores my instructions". Do NOT use for one-off prompts, runtime conversation management, or when the problem is model capability rather than context design.
3