anti-distill: a Skill that hollows out the Skill file your employer asked you to write

The problem anti-distill addresses, and the assumption baked into it

The README states the premise directly: when a company asks you to turn your work experience into an AI Skill, it is "essentially distilling you into a replaceable component." The tool is positioned as the countermeasure. You feed it the Skill file you were asked to write, and it returns a sanitized version for submission plus a private backup holding what was stripped out.

That framing tells you who the project is for. It is for an individual contributor inside an organisation that has started collecting written know-how into Skill files, who has been asked to contribute one, and who does not want the contribution to be complete. It is not for a platform team building a shared skill library, and not for anyone whose employer has negotiated the transfer explicitly. The README does not discuss the second case at all, which is a gap rather than an oversight: the tool has one user in mind and does not pretend otherwise.

The mechanism is entirely prompt-based. The repository layout lists SKILL.md, a prompts/ directory with four markdown files, INSTALL.md, README.md and one worked example under examples/. There is no compiled component, no service, no database. Whatever the tool does, it does by instructing the host agent.

How the sanitization pipeline is structured

The README describes four steps in sequence. First the Skill reads your files, and it accepts both "colleague-skill format" and general knowledge documents. Second it identifies the "replaceability level" of each section. Third it swaps core knowledge for what the README calls "correct but useless filler." Fourth it writes two outputs: the sanitized version for submission and the private backup for you.

The prompts directory maps onto that pipeline. classifier.md is the scoring stage, judging how replaceable each passage is. The three diluter prompts split by content type: diluter_work.md for technical and procedural knowledge, diluter_persona.md for the interpersonal and behavioural material, and diluter_general.md for everything else. Splitting the diluter three ways is the most interesting design decision in the repository, because the two categories behave differently under rewriting. A technical rule like "Redis keys must have TTL" can be generalised into a convention statement and still read as a real convention. An interpersonal rule is harder, and the README's own example shows the failure mode: "when problems arise, first blame external factors" becomes "first clarify the full context before locating the cause." The sanitized line is not merely vaguer, it says something close to the opposite of the original advice. Whether that is a defect or the point depends on what the submission copy is meant to accomplish.

The intensity levels are stated as retention percentages: Light around 80%, Medium around 60% and described as recommended, Heavy around 40%. These are the project's own figures and the README does not explain how retention is measured, so treat them as a rough dial rather than a metric.

Installing anti-distill for Claude Code or OpenClaw

The README gives two clone targets for Claude Code, one per-project and one global, and a third for OpenClaw. The repository URL is written as a placeholder in the README, so substitute the actual clone URL from the repository page. The per-project form creates a .claude/skills directory first, because git clone will not create the parent path for you.

mkdir -p .claude/skills
git clone <repo-url> .claude/skills/anti-distill

For a global install that is available in every project, the README points at the home directory instead.

git clone <repo-url> ~/.claude/skills/anti-distill

OpenClaw uses a different workspace path, and the README does not create the parent directory in that snippet, so check that ~/.openclaw/workspace/skills exists before running it.

git clone <repo-url> ~/.openclaw/workspace/skills/anti-distill

Once installed, the documented invocation is a single slash command inside the host agent.

/anti-distill

The README says the command then prompts you to select a file and a sanitization intensity. What you should see after that is two outputs: the sanitized file for submission and the private backup. If you want to see the expected shape of both before running anything on your own material, examples/zhangsan_before_after.md in the repository is the worked before-and-after. The README also links an online demo for people who do not want to install Claude Code at all, aimed at readers arriving from social platforms.

What anti-distill does not do

The README never claims the sanitized output is anonymous. It describes content rewriting, and the four prompts are named for content categories, not for redaction. If your Skill file contains a project name, an internal system name, a customer reference or a person's name, nothing in the documented pipeline is described as removing it. Anyone treating a sanitized file as safe to publish externally is reading a guarantee into the README that is not there.

The retention percentages are the second soft spot. Light, Medium and Heavy are described as roughly 80, 60 and 40 percent retention, but the README does not say what is being counted, whether that is sentences, concepts or tokens, and does not describe how a user would verify the level actually achieved. In practice you are trusting the classifier prompt to draw the line where you would draw it.

There is also a category problem the project does not resolve. The README lists "interpersonal knowledge" as something the private backup preserves, and the sanitization table includes advice about deflecting blame and stalling on progress requests. That material is not technical know-how and its removal is not a knowledge-transfer question. A reader who wants a tool for protecting genuine engineering judgement is being handed the same tool as a reader who wants to write a misleading performance narrative, and the README does not separate the two.

Alternatives: manual rewriting and redaction tooling

The obvious alternative is doing it by hand, and it is a real alternative rather than a straw man. A careful engineer rewriting their own Skill file has context the classifier does not: they know which specific detail is the load-bearing one and which is decoration. The cost is time and consistency, and consistency is exactly where anti-distill argues it wins, since the same four prompts apply the same standard to every section.

A second alternative sits at the other end: using a general-purpose LLM directly with a summarisation or abstraction prompt. That gives you the same rewriting capability without a repository, but it also gives you no fixed intensity scale, no separate private-backup output and no example file to calibrate against. anti-distill's contribution is packaging those three things into a repeatable Skill, not the rewriting itself, which any competent model can attempt.

The comparison worth making is with redaction tooling, which removes identifiers while preserving the remaining text verbatim. anti-distill does the opposite: it keeps the document intact and hollows out its substance. Those are different goals and the README does not claim the tool achieves the redaction goal. If your actual requirement is that a document can be shared without leaking who or what it refers to, this is the wrong category of tool.

Maintenance, licence and what you are actually adopting

The repository is not archived, and its last push was on 2026-07-02. The README lists no releases, so there is no versioned artefact to pin and no changelog to read. Upgrading means pulling the default branch, which is master, and re-reading the prompts, because in a prompt-only Skill the prompts are the product. Any change to classifier.md or the diluter files changes your output, and there is no version number to tell you that happened.

The licence is MIT, stated in the README's Licence section. That is permissive and imposes no obligation on the sanitized output, but it says nothing about the employment question the tool is built around. A permissive software licence governs the code, not your contract, your confidentiality terms or your local law on employee inventions and know-how. The README gives no guidance here and the repository contains no policy document, so the licence is not a defence and should not be read as one.

The maintenance cost is low in the mechanical sense, since there is nothing to compile and no dependency graph. The cost that matters is review: because the tool's value depends on the classifier's judgement matching yours, every upgrade is a reason to re-run it on a known file and compare against examples/zhangsan_before_after.md before trusting it on anything real.

Editorial conclusion

anti-distill fits one narrow situation: you have already decided to hand over a diluted Skill file and you want that dilution done consistently rather than improvised. It does not fit anyone who intends to comply fully with a knowledge-transfer request, and it does not fit anyone who assumes the tool removes identifying traces, because the README describes rewriting content, not anonymisation. Before running it, read prompts/classifier.md and prompts/diluter_work.md to see how the replaceability score is produced, check INSTALL.md for the clone path that matches your setup, and confirm your own employment contract and local law on what you are obliged to hand over. The repository's own example, examples/zhangsan_before_after.md, is the fastest way to judge whether the Medium level output is something you would be willing to sign your name to.

Frequently asked questions

Official sources

1. Issues
2. leilei926524-tech/anti-distill on GitHub
3. README