Semantic Compression
Shrink prompts, specs, and docs before sending them to Claude, Codex, or Cursor without losing meaning.
Overview
Semantic Compression is a journey-wide agent skill that removes predictable grammar while preserving semantics—usable whenever a solo builder needs to shrink LLM prompts and context before committing tokens.
Install
npx skills add https://github.com/can1357/oh-my-pi --skill semantic-compressionWhat is this skill?
- Two-tier deletion rules (always-delete vs delete-unless-meaning-changes) for articles, copulas, filler, and intensifiers
- Aggressive fragment output: noun stacks, list fragments, label:value—no requirement for full sentences
- LLM-aware stance: drop grammar LLMs reconstruct; keep semantic payload and timeline-critical tense
- Built for token reduction on prompts, bundled context, and token-inefficient documentation
- Two deletion tiers: Tier 1 always-delete and Tier 2 delete-unless-meaning-changes
Adoption & trust: 1 installs on skills.sh; 11.3k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You are stuffing long prose into agent context and paying for tokens the model can infer from content words alone.
Who is it for?
Solo builders who repeatedly paste specs, docs, or logs into agents and want a consistent compression ritual before each session.
Skip if: Human-facing copy that must stay grammatically polished, legal text where every auxiliary matters, or content where tone and cadence are the deliverable.
When should I use this skill?
Compressing text for prompts, reducing token count, preparing context for LLM input, or making documentation more token-efficient.
What do I get? / Deliverables
You get shorter, fragment-style text that preserves meaning for the model, with lower token use on the next agent turn.
- Compressed fragment-style text preserving semantic payload
- Token-reduced prompt or context block ready for LLM input
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Compress a verbose feature brief into fragment lists before asking an agent to estimate scope.
Strip scaffolding from pasted API docs before a coding agent implements an integration.
Shorten a long PR discussion thread into semantic bullets for a review agent.
Compress stack traces and log excerpts before feeding them into a debug agent.
Token-tighten research notes you will reuse across multiple content-generation agent runs.
How it compares
Use instead of manual “delete fluff” editing in chat when you want repeatable LLM-aware deletion tiers in a skill.
Common Questions / FAQ
Who is semantic-compression for?
Indie and solo developers using Claude Code, Cursor, Codex, or similar agents who need smaller prompts and context bundles without rewriting meaning by hand.
When should I use semantic-compression?
During build agent-tooling when trimming implementation context; during validate when condensing scope notes for a planning agent; during ship when compressing long test or review logs; during operate when summarizing incident threads for the next diagnostic turn; and anytime you
Is semantic-compression safe to install?
It is text-transformation guidance with no shell or network requirements by default; review the Security Audits panel on this Prism page before trusting any third-party skill package in your repo.
SKILL.md
READMESKILL.md - Semantic Compression
# Semantic Compression LLMs reconstruct grammar from content words. Remove predictable glue; keep semantic payload. Prefer fragments over sentences. ## Aggressive Stance - Output can be noun/verb stacks, list fragments, or label:value phrases. - Default to deletion; keep function words only when loss changes meaning. - Prefer base verb forms; drop tense/aspect unless timeline is critical. ## Deletion Tiers **Tier 1 — Always delete (even if fragments):** - Articles: a, an, the - Copulas: is, are, was, were, am, be, been, being - Expletive subjects: "There is/are...", "It is..." - Complementizer: that (as clause marker) - Pure intensifiers: very, quite, rather, really, extremely, somewhat - Filler phrases: "in order to" → to, "due to the fact that" → because, "in terms of" → delete - Infinitive "to" before verbs (unless it prevents noun/verb confusion) - Conjunctions when list/contrast obvious: and, or, but **Tier 2 — Delete unless meaning changes:** - Auxiliary verbs: have/has/had, do/does/did, will/would (keep if tense/aspect matters) - Modal verbs: can/could/may/might/should (keep when obligation/permission/possibility is critical; always keep must/must not) - Pronouns: it/this/that/these/those/he/she/they (drop when referent obvious; replace with noun if ambiguous) - Relative pronouns: which, that, who, whom - Prepositions: of, for, to, in, on, at, by (keep for material, direction, agency, or disambiguation) **Tier 3 — Delete only if relation still clear:** - Remaining prepositions: with/without, between/among, within, after/before, over/under, through (drop only if relation obvious) - Redundant adverbs: "shout loudly" → "shout" ## Always Preserve - Nouns, main verbs, meaning-bearing adjectives/adverbs - Numbers, quantifiers: "at least 5", "approximately", "more than" - Uncertainty markers: "appears", "seems", "reportedly", "what sounded like" - Negation: not, no, never, without, none - Temporal markers: dates, frequencies, durations - Causality and conditionals: because, therefore, despite, although, if, unless - Requirements/permissions: must, required, prohibited, allowed - Proper nouns, titles, technical terms - Prepositions encoding relationships: from/to (direction), with/without (inclusion), between/among/within (relation), after/before (temporal), by (agent if passive) ## Structural Compression - Passive → active when agent known: "was eaten by dog" → "dog ate" - Nominalization → verb: "made a decision" → "decided" - Drop implied subject when context allows: "System should log errors" → "Log errors" - Redundant pairs → single: "each and every" → "every" - Clause → modifier: "anomaly that was reported" → "reported anomaly" ## Examples | Original | Compressed | |----------|------------| | The system was designed to efficiently process incoming data from multiple sources | System design: efficient process incoming data, multiple sources | | There were at least 20 people who appeared to be waiting | At least 20 people apparent waiting | | It is important to note that the medication should not be taken without food | Medication: should not take without food | | The researcher made a decision to investigate the anomaly that was reported | Researcher decided: investigate reported anomaly |