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 prismgit 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/prism)<a href="https://agentmods.dev/skills/lilmgenius/paperthin/prism"><img src="https://agentmods.dev/badge/skills/lilmgenius/paperthin/prism/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/prism"><img src="https://agentmods.dev/badge/skills/lilmgenius/paperthin/prism.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.00098 | $0.00653 |
| Opus 5.5 | $0.00039 | $0.00261 |
| Sonnet 5.5 | $0.00020 | $0.00131 |
| Haiku 4.5 | $0.00010 | $0.00065 |
Grade A, and why
prism 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:
- prism — 100% identical
How it starts
The opening of the file, as written. The whole thing — 35 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Split one artifact across independent lenses and return where they converge and where they don't.
Goal
The result is a picture of where the lenses agree, where they disagree, and the smallest question that would resolve the disagreement. Not a checklist, and never an average — averaging the lenses is the failure this skill exists to prevent.
Workflow
- Read the artifact end to end before choosing the lenses.
- Choose one lens per genuinely distinct failure mode — correctness, security, readability, cost, adversarial-user, and the like. Two candidate lenses that share a failure mode are one lens, not two. In practice this lands between 2 and 5: below 2 there is nothing to converge, and past 5 you are almost always padding with lenses that overlap. There is no default count — the artifact's distinct failure modes set it.
- Through each lens, produce a one-line verdict — pass, fail, or unclear — with its single most load-bearing reason. No hedging list; if a reason isn't load-bearing, drop it.
- Compare the verdicts and group them: full agreement, agreement for different reasons, disagreement.
- Where there is disagreement, name the single next question whose answer would move it into agreement or a clean split with owners. That question is the output, not the individual verdicts.
- Where every lens agrees, return the shared verdict with the reasons that were load-bearing for at least two lenses.
Rules
- Independent lenses, not roles. A "security reviewer" and a "senior security reviewer" are one lens, not two.
- One reason per lens — the load-bearing one. A lens that returns a list is hedging.
- Disagreement is the product. A prism that agrees on everything did not need to be run.
- Never average. If two lenses split, the answer is the question that resolves the split, not the midpoint of their verdicts.
- Draw the lenses fresh for the artifact in hand. A lens useful for a spec may be useless for a migration; don't carry lenses across artifacts.
- Don't manufacture disagreement. A run that finds none returns the shared verdict and stops.
- User-invoked on purpose: plural lenses are an opt-in spend, and their convergence must never masquerade as automatic proof, so this fires only when deliberately reached for.
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 · 35 lines · 98 tokens per session scan A c7ed6a24e508
prism is a skill published in the GitHub repository LilMGenius/paperthin (1,278 stars, last pushed today), licensed MIT. It adds 98 tokens to every session and 653 once invoked, about $0.0004 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
second-opinion
GPT (GPT-6 Astra by default) as advisor, adversarial reviewer or judge through headless codex exec, always read-only; never an implementer. Modes: advise (independent read on a plan, diff or design, beside Claude's own view, with follow-ups), review (Codex's built-in reviewer on uncommitted work, a branch or a…
clean-code
Use when writing, editing, reviewing, testing, planning, or refactoring code in any language or framework; creating files or deciding where code and folders belong; designing or changing module boundaries, layers, and dependencies; starting a new project; auditing or cleaning up an existing one; or compressing agent…
insistir
Run a task through an agent team where every worker's output is cross-reviewed, judged by a second provider and fixed by fresh agents until APPROVED.
solid-interface-segregation
This skill should be used when the user asks about "interface segregation", "ISP", mentions "fat interfaces", discusses clients forced to depend on methods they don't use, or wants to design smaller, focused interfaces.
solid-single-responsibility
This skill should be used when the user asks about "single responsibility", "SRP", mentions "separation of concerns", discusses classes doing too much, or wants to identify when a class has multiple reasons to change.
branch-review
This skill should be used when the user asks to "review a branch", "compare code quality", mentions "branch review", "code quality scorecard", discusses comparing old vs new code, or wants a scored assessment of changes on a feature branch.