agentleFS
voxlo-devvoxlo-dev/Lean-Coding-Workspace/.agents/skills/compress/SKILL.md

compress

Skill2 starsChanged 4 days agoMITView on GitHub

Use when writing or editing any Markdown in this repo (CLAUDE.md, a SKILL.md, AGENTS.md, project_TEMPLATE, README), and again when a finished section reads fat or the user asks for token compression. Two modes: compress-on-write lands the edit in final form, compress-after-write re-passes existing text.

17 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use caveman-review, caveman-commit and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • huangzidaSkill

    caveman-review

    Ultra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", "/review", or invokes /caveman-review. Auto-triggers when reviewing pull requests.

    Also in 3 projects that use this

  • huangzidaSkill

    caveman-commit

    Ultra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. Use when user says "write a commit", "commit message", "generate commit", "/commit", or invokes /caveman-commit. Auto-triggers when staging changes.

    Also in 3 projects that use this

  • MicrosoftSkill

    caveman

    Ultra-compressed response style that reduces output token count while preserving technical accuracy, with intensity levels and auto-clarity safety rules

    Also in 6 projects that use this

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 13 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify against the map: every rule still present, and report the size delta.

    line 37

“Common” is measured: kept by at least 6 in 10 of the 13 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Compress

Two modes, best used together: write compressed, then re-pass the finished section. On-write gets the shape right — a fat draft trimmed later keeps its seams. After-write catches what only becomes visible once the whole thing exists: duplication across sections, a rule that outgrew its host, scaffolding nobody reads.

The five tests

Both modes run these. Every line here is read by a model mid-task.

  • Behaviour — what does the model do differently because of this line? Nothing → it doesn't exist.
  • Host — does a list, table row or sentence already cover the topic? Then the rule belongs inside it; a fresh section is the last resort.
  • Home — is the fact already stated elsewhere in the repo? Reference it, never restate. Grep before assuming it isn't.
  • Seam — can a reader tell which lines are new or touched? Visible seams mean an explaining voice or a block where an integration belonged.
  • Deletion — remove the clause; does any agent behave differently? No → it stays removed.

Compress on write

  1. Answer behaviour, host and home before typing — the host decides where the edit goes, so find it first.
  2. Rules, not reasons. State the imperative; add the why only where an agent would otherwise break the rule, as one clause in the same sentence.
  3. Clause > sentence > paragraph. Merge related rules with · or — rather than listing them.
  4. Match the surrounding density — the voice of the lines above and below, not your natural one.
  5. Cut on sight: preamble, "note that", restated rationale, examples where the rule is already unambiguous, hedges, any recap of what the text just said.
  6. Seam and deletion test on the new lines, then save.

Compress after write

On a finished file or section, never mid-draft.

  1. Read it whole first. Local edits without the full picture create the duplication you came to remove.
  2. Map what it asserts — one line per rule. Two lines saying the same thing → merge into the stronger host. A rule with a home elsewhere → replace with a reference.
  3. Deletion test every clause, top to bottom. Delete first, restore only what fails the test.
  4. Rewrite the survivors into the fewest sentences that keep every rule. Restructure the host — shaving words while the structure stands is what leaves seams, and buys little.
  5. Verify against the map: every rule still present, and report the size delta.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.