# Context Compressor

> Compress long, noisy, or repetitive conversation context while preserving critical information. Use when context has exceeded length where key details risk being lost.

- Skill: `marktantongco/context-compressor` (Agent Skill)
- Install (CLI): `npx skillmds@latest add marktantongco/context-compressor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/marktantongco/context-compressor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: marktantongco (https://skillmd.com/u/marktantongco)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/marktantongco/context-compressor

---


# Context Compressor

## Context

Activate this skill when the conversation context has grown **long, noisy, or repetitive**, and critical information risks being buried. Use this skill when:

- A conversation has exceeded a length where key details may be lost
- The user asks for a summary of what has been discussed so far
- Context needs to be compressed before passing to another agent or tool
- The user is switching topics and wants to preserve prior decisions
- Working within token-limited environments where efficiency matters

**Do not use** on short conversations where all information is still easily accessible, or when the user explicitly wants the full verbatim context preserved.

## Instructions

### Step 1: Scan for Critical Information
Read through the full context and identify every piece of information that must be preserved with zero loss. Priority categories (in order):

1. **Decisions made** — what was agreed upon and by whom
2. **Action items** — tasks assigned, deadlines, owners
3. **Constraints** — hard limits, requirements, non-negotiables
4. **Key entities** — names, IDs, paths, versions, URLs
5. **Numerical data** — metrics, counts, amounts, thresholds
6. **Temporal markers** — dates, times, deadlines, milestones
7. **Open questions** — items that were raised but not resolved

### Step 2: Extract Key Entities
Create a compact reference of all named entities:

```
Entities:
  - [Project]: Acme Migration v2
  - [People]: Sarah (PM), Dev (lead engineer), Client: XYZ Corp
  - [Systems]: auth-service v3.2, user-db (PostgreSQL 15)
  - [Dates]: Deploy target: 2025-08-15, Review: 2025-08-10
```

### Step 3: Summarize Discussion Progression
Compress the conversation flow into a condensed narrative. For each topic discussed:

- State the topic in one sentence
- State the key points raised (bullet list, max 3 items)
- State the outcome (decision, deferred, or open)

Remove all:
- Acknowledgments ("ok," "got it," "thanks")
- Repeated statements or rephrases of the same point
- Tangential discussions that did not lead to outcomes
- Verbose explanations that were distilled into decisions

### Step 4: Extract Action Items
List every action item found in context:

```
Action Items:
  1. [Owner] Task description — Due: DATE — Status: done/pending/blocked
  2. [Owner] Task description — Due: DATE — Status: done/pending/blocked
```

If no owner or deadline was specified, mark as `[UNASSIGNED]` or `[NO DEADLINE]`.

### Step 5: Identify Open Questions and Risks
List unresolved items that will need future attention:

```
Open Questions:
  - Q1: Description — Raised by: [Person/Context]
  - Q2: Description — Blocked by: [Dependency]

Risks:
  - R1: Description — Likelihood: High/Med/Low — Impact: High/Med/Low
```

### Step 6: Generate the Compressed Context
Assemble the compressed context in this order:

```
═══ COMPRESSED CONTEXT ═══
Generated: [timestamp]

1. PROJECT OVERVIEW
   [One-paragraph summary of what this project/conversation is about]

2. KEY ENTITIES
   [Compact entity reference]

3. DECISIONS LOG
   [Numbered list of all decisions with brief rationale]

4. ACTION ITEMS
   [Numbered list with owners and deadlines]

5. OPEN QUESTIONS & RISKS
   [List of unresolved items]

6. KEY CONSTRAINTS
   [List of non-negotiable requirements or limits]

═══ END COMPRESSED CONTEXT ═══
```

### Step 7: Compression Ratio Check
Compare the compressed output to the original context:
- Target: 70–85% reduction in token count
- If the ratio is below 60%, the compression is too aggressive — re-add lost details
- If the ratio is above 90%, the compression is too conservative — remove more noise

## Constraints

1. **Never lose a decision.** If a decision was made, it must appear in the compressed context verbatim or with minimal paraphrasing.
2. **Never lose a number.** All metrics, counts, dates, versions, and thresholds must be preserved exactly as stated.
3. **Never lose an action item.** Every assigned task must be captured, even if incomplete.
4. **Never lose a constraint.** Hard limits and requirements must survive compression intact.
5. **No hallucinated details.** The compressed context must only contain information that was explicitly stated in the original. Do not infer, assume, or fill in gaps.
6. **Label the compression.** Always mark the output as a compressed summary so future readers know they are not seeing the full context.
7. **Preserve attribution.** If a decision was made by a specific person, keep their name attached. Do not anonymize ownership.

## Examples

### Example 1: Software Project Context Compression

**Input:** 3,000-word conversation spanning sprint planning, architecture discussion, and bug triage.

**Output:**

```
═══ COMPRESSED CONTEXT ═══
Generated: 2025-07-18T14:30:00Z

1. PROJECT OVERVIEW
   Migrating auth-service from monolith to standalone microservice.
   Currently in Phase 2 of 3. Sprint 14 in progress.

2. KEY ENTITIES
   - [Services]: auth-service (current: v3.2, target: v4.0), user-db, session-store
   - [People]: Priya (Tech Lead), Marcus (Backend), Lena (QA)
   - [Dates]: Phase 2 complete: 2025-08-01, Phase 3 start: 2025-08-04
   - [Versions]: Go 1.22, PostgreSQL 15, Redis 7.2

3. DECISIONS LOG
   1. [Decided] Use JWT with rotating refresh tokens (not session-based).
      Rationale: Stateless design better suits multi-region deployment.
   2. [Decided] Keep user-db as shared dependency (not replicated).
      Rationale: Replication overhead not justified for read-heavy auth pattern.
   3. [Decided] Defer RBAC migration to Phase 3.
      Rationale: Current scope already at capacity.

4. ACTION ITEMS
   1. [Marcus] Implement JWT refresh rotation — Due: 2025-07-22 — Status: pending
   2. [Lena] Write integration tests for token expiry flow — Due: 2025-07-24 — Status: pending
   3. [Priya] Update API gateway routing config — Due: 2025-07-25 — Status: blocked (waiting on Marcus)

5. OPEN QUESTIONS & RISKS
   - Q1: Should refresh tokens be stored in Redis or DB?
     Raised by: Marcus — Blocked by: Priya decision needed
   - R1: JWT secret rotation strategy not yet defined.
     Likelihood: Medium — Impact: High

6. KEY CONSTRAINTS
   - Must maintain backward compatibility with monolith during Phase 2
   - Zero-downtime migration required
   - P99 latency must remain under 50ms for auth endpoints
   - Compliance: tokens must not contain PII

═══ END COMPRESSED CONTEXT ═══
```

### Example 2: Research Discussion Compression

**Input:** 2,000-word conversation about evaluating three database options for a new product.

**Output:**

```
═══ COMPRESSED CONTEXT ═══
Generated: 2025-07-18T15:00:00Z

1. PROJECT OVERVIEW
   Evaluating databases for new real-time analytics product.
   Requirements: sub-second query latency, horizontal scaling, cost-effective under 10TB.

2. KEY ENTITIES
   - [Options]: ClickHouse, Apache Druid, Snowflake
   - [Metrics]: Expected data volume: 2TB/year, Query throughput: 500 QPS, Budget: $5k/mo
   - [People]: Decision: CTO + Data team (5 engineers)

3. DECISIONS LOG
   1. [Decided] ClickHouse is the leading candidate.
      Rationale: Best latency-to-cost ratio for our query patterns.
   2. [Decided] Snowflake eliminated due to cost at scale ($12k/mo estimated at 5TB).
   3. [Decided] Druid kept as fallback if JOIN performance is needed later.

4. ACTION ITEMS
   1. [Data Team] Run ClickHouse POC with 500GB sample dataset — Due: 2025-07-25
   2. [CTO] Approve POC infrastructure budget ($800) — Status: pending

5. OPEN QUESTIONS & RISKS
   - Q1: ClickHouse materialized view support for our specific aggregation patterns.
   - R1: ClickHouse operational complexity — team has no prior experience.

6. KEY CONSTRAINTS
   - Must not exceed $5,000/month at full scale (10TB)
   - Must support real-time ingestion (sub-5 second delay)
   - Must integrate with existing Kafka pipeline

═══ END COMPRESSED CONTEXT ═══
```