Hush compress
π€« Token-lean sessions at the harness level. An easy to grasp output style, output-shrinking hooks, and log compression cut both input and output tokens.
npx -y skills add V-Songbird/hush --skill hush-compressAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
What its author says it does
Copied from the file, not written here
Compresses a memory file (CLAUDE.md, project notes, preferences) into hush's own dev-shorthand voice to cut input tokens every session it's loaded. Never touches the original file β writes a sibling file for the user to review and swap in manually. A mechanical verifier checks that headings, code blocks, URLs, paths, and inline code all survived.
SKILL.md
4.8 KB, as published. Nobody here has run it
hush:hush-compress
Shrinks a memory file's word count using hush's own voice β the same "Word economy" rules the output style already applies to conversation β so every future session that loads this file pays fewer input tokens for it. Never writes to the original.
1. Refuse before reading, if the path matches any of
.env (or .env.*), .netrc, credentials*, secrets*, passwords*, id_rsa/id_ed25519 (or .pub), authorized_keys, known_hosts, any *.pem/*.key/*.p12/*.pfx/*.crt/*.cer/*.jks/*.keystore/*.asc/*.gpg, or any path containing a .ssh/, .aws/, .gnupg/, or .kube/ component.
Tell the user why and stop. Do not read the file. These are exactly the kinds of files that must never reach a model call.
2. Read the file, refuse if empty
If the file is empty or whitespace-only after reading, say so and stop β nothing to compress.
3. Compress the body, not the whole file
If the file starts with YAML frontmatter (--- ... ---), leave it completely untouched β copy it verbatim into the output. Compress only the body below it.
Apply hush's own word economy β see output-styles/hush.md:
- Say it in the fewest words that stay understandable. Before keeping a sentence, ask: can this lose a word without losing a fact? If yes, cut it.
- Default to fragments, not sentences. Drop articles, hedges, and connective tissue a reader fills in on their own.
- This is dev-shorthand density, not broken grammar: grammar stays correct where it's present, technical terms stay exact, nothing is invented or abbreviated beyond recognition.
Preserve these EXACTLY, byte for byte β never reword, shorten, or paraphrase inside them:
- fenced code blocks and inline code (
`like this`) - URLs and markdown links
- file paths and shell commands
- technical terms, proper nouns, library/API names
- version numbers, dates, numeric values
- environment variable names (
$HOME,NODE_ENV) - heading text and heading order
4. Write the result to a sibling file β never the original
For some/path/CLAUDE.md, write to some/path/CLAUDE.hush.md. For any other filename, insert .hush before the extension (notes.md β notes.hush.md). This is the whole safety model: the original's bytes are never touched by this skill, in any step, so there is no path by which running this can damage or delete the source file.
5. Check cache stability (advisory only)
Run:
node "${CLAUDE_PLUGIN_ROOT}/scripts/cache-stability-check.js" <original>
This scans the ORIGINAL file's first 60% of lines for volatile content β ISO dates, times, AUTO-GENERATED/Last updated/Generated by stamps, UUID-v4s, and @import lines whose paths carry a date or build stamp. These lines sit early in the prompt-cache prefix; every session that changes one re-bills everything after it. This never edits the file β it's advisory only. Include any findings in your report to the user (move-or-remove suggestion); if it reports clean, no need to mention it.
6. Verify mechanically
Run:
node "${CLAUDE_PLUGIN_ROOT}/scripts/verify-compression.js" <original> <compressed>
This checks that every heading, code block, URL, path, and inline-code span in the original still appears somewhere in the compressed file. It exits 1 and lists what's missing if not β it doesn't block anything (there's nothing destructive to block), it's evidence for you to look at before reporting back.
If something is flagged missing, look at whether it actually mattered (the checker is deliberately crude and can flag things like a URL fragment as a false "path") β restore anything real that got dropped, by editing the sibling file, before reporting.
7. Report
One line: original word count β compressed word count, percent saved, where the sibling file was written. If the verifier flagged anything worth mentioning, say what and whether you fixed it. If the cache-stability check found anything, name the flagged lines and suggest moving them to the end of the file or removing them. Tell the user to review the sibling file and manually replace the original (or ask them to rename it) once they're satisfied β this skill never does that replacement itself.