Paperthin is a collection of low-level design patterns that coding agents can apply as repeatable checks and actions during software work. It is for people using agents such as Claude Code, Codex, Cursor, or other supported tools, and its catalogue entries package the patterns as skills, an instruction, and a plugin.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add LilMGenius/paperthin --skill re0-mergegit clone --depth 1 https://github.com/LilMGenius/paperthinWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/lilmgenius/paperthin/re0-merge)<a href="https://agentmods.dev/skills/lilmgenius/paperthin/re0-merge"><img src="https://agentmods.dev/badge/skills/lilmgenius/paperthin/re0-merge/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/lilmgenius/paperthin/re0-merge"><img src="https://agentmods.dev/badge/skills/lilmgenius/paperthin/re0-merge.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket pass
- Snyk pass
- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00070 | $0.01049 |
| Opus 5.5 | $0.00028 | $0.00420 |
| Sonnet 5.5 | $0.00014 | $0.00210 |
| Haiku 4.5 | $0.00007 | $0.00105 |
Grade A, and why
re0-merge scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- re0-merge — 100% identical
How it starts
The opening of the file, as written. The whole thing — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Land a contribution fairly: credit preserved, the maintainer's changes legible, accepted on the record.
Goal
A contribution is a gift with a permanent carrying cost, and a review either honors both or fails one. re0-merge walks whoever reviews — any collaborator or maintainer, not just the author — through accepting a pull request the way this suite does: judged against the thesis, landed with the author's authorship intact, the maintainer's own edits kept as separate commits, and closed with an approval and a credit rather than a silent rejection.
Workflow
- Gate before landing. An additive contribution is declined by default; the burden is on the addition to show the suite is worse without it, not on you to justify a no. Judge each PR alone, never as a batch: a bug-fix subtracts a defect and is the easy yes; new tooling earns a place only if it mechanizes a rule already enforced by hand; a new skill lands only if it closes a real gap no existing one covers. A well-reasoned decline is a shipped outcome, not a failure.
- Cold-read it first. Read the contribution end to end with fresh eyes (a
showerpass when installed) before deciding; a name or claim that reads clean to its author may not to a stranger. - Verify, do not re-fix. Where the author already pushed a fix, prove it with a throwaway regression case rather than rewriting it; the credit for the fix is theirs.
- Approve as you accept, then land on a
land/pr-<n>branch (a range only for a genuine multi-PR batch). Submit the approving review the moment you decide to accept, before the land — it is a verdict on the contributor's code, not a receipt for a release, and giving it now (not bundled with the later close) is what keeps a closed-not-merged PR reading as accepted. Then accept each contributor commit with its authorship preserved (you become the committer; clean the message withre0-git), add every maintainer change as its own separate commit so the credit split stays legible, and fast-forward intomain. - Complete a new skill, don't merge it raw. Get the name right (a plain real word or tight compression, no opaque coinage), the invocation right (model- vs user-invoked), and the home right; then register it on every roster surface (
plugin.json, the README Index in root and every localized copy,re0-upgrade's Current catalog,scripts/catalog.cjs) so no drift-guard trips. - After the release the contribution shipped in confirms, close the PR with the comment. Close it in the same motion as a comment that credits and explains — never a silent close, and never before the release lands. The approval from step 4 already records it as accepted; this step only closes and explains.
- The comment credits and explains, warmly. Shout the contribution out in the release notes with its PR number and author handle; and if you renamed or reframed anything, the closing comment thanks the author, says what changed and why, points at the release it shipped in, and hands the credit for the core idea back to them.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 40 lines · 70 tokens per session scan A f07ed97a8212
re0-merge is a skill published in the GitHub repository LilMGenius/paperthin (1,333 stars, last pushed today), licensed MIT. It adds 70 tokens to every session and 1,049 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
check
Reviews diffs, PRs, release readiness, and publishing follow-through. Use when asked to review, triage issues or PRs, or ship. Not for debugging root causes or prose.
antfu-create-pr
Create a reviewable GitHub pull request from the current branch with a Conventional Commits title, a concise evidence-based body, and before/after screenshots for UI changes. Use when asked to open, create, publish, or prepare a PR.
factory-babysit-pr
Experimental workflow for babysitting one explicitly authorized pull or merge request. Use to monitor its live review state and checks, fix actionable in-scope findings, and apply separate reply, approval, merge, and soak gates.
factory-review-prs
Experimental workflow for reviewing configured repositories' pull requests. Use for manual or scheduled PR triage, approval, or merge decisions.
comet-github-pr-review
A read-only review process for pull requests in Comet's GitHub repositories. A pull request is a proposed code change; the review checks its current code, related issue, comments, merge status, and automated checks.
flow-next-worktree-kit
Manage git worktrees (create/list/switch/cleanup) and copy .env files. Use for parallel feature work, isolated review, clean workspace, or when user mentions worktrees.