compressing-knowledge
Skill0 starsChanged 28 days agoMITView on GitHub
Compresses documents, prompts, or knowledge sources into fewer tokens while verifying that every answerable fact survives, using a test-question harness graded by a fresh, source-blind agent. Use when asked to shrink a doc, README, or prompt losslessly, cut token or context-window footprint without losing information, or confirm a compression keeps every fact intact.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- writing-skillsSkill
- building-wikiSkill
- creating-issuesSkill
- designing-cliSkill
- fuckSkill
- functional-domain-modelingSkill
- git-shippingSkill
- no-commentsSkill
- orchestratingSkill
- receiving-code-reviewSkill
- tracking-tasksSkill
- writing-japaneseSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
No subagent can run with a genuinely empty context (see Verification) — say so.
- Distinctive: line 29
All pass → new safe anchor.
- Very specific: line 40
Every grading subagent is a fresh, non-fork Agent call (e.g.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Compressing Knowledge
Compression is trustworthy only if something that never saw the original can still pass a test on it. Treat every draft as unverified until then.
When Not To Use
- Some information loss is acceptable — just summarize; the harness is overkill.
- The task is prose style or code tightening, not fact preservation — use a style or simplification pass instead.
- No subagent can run with a genuinely empty context (see Verification) — say so; offer only an unverified summary if still wanted.
Workflow
- Baseline. Record the source's token count with a consistent proxy (
wc -wis enough; only consistency across iterations matters). - Extract test questions. Before drafting, pull out question/answer pairs, each grounded in one distinct fact and traceable to a specific passage. Scale count to length: roughly one per 40 source tokens, minimum 5, or the user's stated count. Done when no two questions share a fact and every answer is written down.
- Verify the harness. Give a grading subagent only the original source and the bare questions (no answers). Grade its answers against the recorded ones yourself. A failure means the question is ambiguous or ungrounded — fix or drop it and re-run until the source passes every question. This is the ground truth later drafts are measured against.
- Cut, then test. Cut redundancy, restatement, and filler into a candidate draft — cutting content, not whitespace or formatting, which doesn't reduce real footprint. Give a grading subagent only the candidate draft (never the original) and the bare questions; grade its answers.
- All pass → new safe anchor. Return here and cut further.
- Any fail → floor found; go to step 5.
- Repair. Patch the failing draft with the minimum addition that restores the missing fact(s) — don't revert wholesale to the last anchor. Re-test until it passes every question, then retry step 4 from the repaired draft.
- Stop. Finish when two consecutive repair-then-shrink attempts fail to beat the last safe anchor's size, or a user-given budget is exhausted. Never hand back a draft that hasn't itself passed every question.
- Report. Deliver the final text plus: baseline and final token counts and reduction %, the full question/answer set (for re-verifying future edits), and an iteration log (draft tokens → pass/fail → what failed → repair made).
Verification
Every grading subagent is a fresh, non-fork Agent call (e.g. general-purpose): a fork inherits your context, including the source, which defeats the test. Without one, verification is unavailable — say so plainly, and never claim the result is lossless.
Grade strictly: a hedge ("not stated"), a partial answer, or a wrong fact all count as failure — the method depends on treating "probably fine" as failure.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

