Paperthin: agent skills that turn engineering hygiene into reflexes

The problem Paperthin names: drifted artifacts and scattered truth

Agents are good at producing text and bad at keeping it clean. The README frames the failure in two axes. Depth asks whether one artifact is still clean and true. Breadth asks whether one fact stays consistent everywhere it appears. A file that has been patched six times, or a rule restated in four documents, is the target. Paperthin's answer is not a linter. It is a set of named procedures the agent reaches for on its own, described in the README as "old engineering wisdom" turned into reflexes.

The intended user is someone already running a coding agent through real work. The README lists Claude Code, Codex, OpenCode, Antigravity, Copilot, Cursor, Grok-Build, Pi, Hermes and OpenClaw, and claims the skills work on any agent. That claim matters because the skills are Markdown instructions, not code bound to one vendor's plugin API. The repository ships a .claude-plugin directory and an AGENTS.md alongside the skills, so at least one agent gets a native plugin path while others read the same files through their own conventions.

How the skills are organized: depth, breadth, coil and mesh

The catalog is split into four directories, each answering a different question. depth covers one artifact right now: re0 rewrites a drifted artifact into a clean v0 rather than adding another patch, dedash removes em-dashes and look-alikes by choosing the punctuation each spot needs, debloat compresses an artifact to what the README calls its load-bearing density. breadth covers many artifacts at once, with ssotize auditing scatter and consolidating to one home. coil covers one project across iterations, where re0-loop runs a build, QA, memo and work cycle. mesh covers many minds across rounds.

Each skill has a SKILL.md file, and the index table lists three properties per skill: scope, invoker and read-only. Invoker is either model or user. That distinction is the practical one. A model-invoked skill such as readchk or shower can fire without you asking. A user-invoked skill such as hate or reorder waits for you to call it by name. The read-only column marks skills that inspect without writing, so you can run shower or factchk against an artifact without expecting edits.

The naming is idiosyncratic, and that is a real cost. Nothing in the word detool tells you it replaces incidental stack nouns with the mechanism they mean. You will read the index before you can use the catalog fluently.

Installing Paperthin with the skills CLI

The README's quickstart is one command. It installs for every agent you use, with the wildcard agent flag and the global flag so the skills land outside a single project.

npx skills@latest add LilMGenius/paperthin --global --agent '*'

After it runs, the README says to run the same shell elevated or as admin if your OS asks, because that is what lets the skills be symlinked rather than copied. Symlinking is the mechanism behind auto-update.

Running your first skill and keeping the install current

Once installed, call any skill by name. The README gives /re0 as the example and notes that model-invoked skills also fire on their own, so readchk or shower can appear without you typing anything.

/re0

To update, the README points at /re0-upgrade, which it describes as upgrading to the full current catalog in one command: retiring renamed skills, adding new ones, with everything confirmed first. That same skill wires what the README calls a quiet session-start notice for when new skills ship.

/re0-upgrade

Where Paperthin is the wrong tool

The catalog assumes an agent that reads and follows long Markdown instructions. If your agent ignores SKILL.md files or truncates them, the skills are inert text on disk. The README describes no fallback execution path, so the failure mode is silent: the install succeeds and the behavior never appears.

There is also a scope boundary. Paperthin operates on artifacts and facts, not on running systems. It has no skill for watching a service, reading logs or responding to an incident, and the topics list is documentation, hygiene, evals and design patterns rather than observability. If your problem is a production regression, this is not the tool.

One more constraint worth stating plainly: the README does not document rollback. There is an upgrade path through /re0-upgrade, but no described way to pin a version or revert a skill that changed behavior under you. The package.json carries a version field at 0.17.5, and the releases page shows v0.17.5, v0.17.4 and v0.17.3, so the project does version its output. How you hold a specific version in place is not covered.

What Paperthin is not: a comparison with repository linters

A conventional linter such as markdownlint or a prose checker applies fixed rules to files and returns a list of violations. It runs in CI, it is deterministic, and it never rewrites your argument. Paperthin takes the opposite approach. The rules live in natural-language skill files, the agent decides when to apply them, and several skills edit the artifact rather than reporting on it.

That difference cuts both ways. A linter gives you a reproducible pass or fail you can gate a merge on. Paperthin gives you judgment: dedash has to pick the punctuation each spot needs, which a regex cannot do well, and re0 has to decide what counts as drift. The trade is determinism for coverage of cases no rule can enumerate. If you need a CI gate, keep the linter. If your problem is that an agent keeps patching a file instead of rewriting it, a linter has nothing to say.

Maintenance, licensing and what an upgrade costs you

The last push was on 2026-09-06, and v0.17.5 was released the same day. The repository is not archived. The release cadence visible in the repository is three releases across roughly three weeks in August and September 2026, which tells you the catalog is moving, and moving catalogs rename things. The README anticipates exactly that: /re0-upgrade is described as retiring renamed skills and adding new ones, all confirmed first. Budget for a periodic review of which skills you actually use, because the upgrade path is designed to change your install, not just extend it.

The license is MIT, declared in package.json and present as a LICENSE file at the repository root. MIT is permissive: you can use, modify and redistribute the skills, including commercially, provided the copyright notice and permission notice travel with copies. There is also a NOTICE file, which is a convention more common in Apache-licensed projects; its contents are not shown in the repository listing, so read it before you redistribute. This is a description of the license text, not legal advice.

The real upgrade cost is not the command. It is that model-invoked skills can change behavior without you invoking anything. A skill that starts firing on its own after an upgrade changes what your agent does mid-task. Confirmation prompts in /re0-upgrade are the only described control over that.

Editorial conclusion

Adopt Paperthin if your agents already produce artifacts you have to clean up by hand, and you want those cleanups to fire from the model rather than from your memory. Do not adopt it if you need a library with a stable API surface: this is a skill catalog installed into your agent, and its behavior depends on the agent reading SKILL.md files. Before relying on it, verify two things: that your agent actually loads the skills after the npx skills@latest add command, and that the install symlinked rather than copied, since the README ties auto-update to symlinking. Both are checkable in a minute and both change what you get.

Frequently asked questions

Official sources

1. License: MIT
2. LilMGenius/paperthin on GitHub
3. Project website
4. README
5. Releases