demock
Skill1.4k starsChanged todayMITView on GitHub
Find the mocks, stubs, fakes, hidden fallbacks and placeholder implementations standing on a real code path outside the tests, where nothing real runs and a success report is false, and propose the real dependency or an honest failure for each. Use when a change or a named file, directory or diff may ship a test double or a swallowed error into production, when a catch or except returns an empty list, None, a default or true, when a guard lets a request through because its key, config or input is missing, when a function raises NotImplementedError or returns a TODO value on a live path, when a feature reports success but nothing seems to happen, or before calling work done that touched error handling, integrations or service clients.
Trending
Less talk lately.thin dataabout the whole repository
Who's talking about LilMGenius/paperthin
- LowyShin/giip-fde-agent“Paperthin 핵심 기능 도입 작업 지시서”GitHub · Jul 26, 2026 · 1 reactions
- dragoscirjan/ai“Refactor and Debloat skill”GitHub · Nov 6, 2026
- tranhoangnguyen03/pi-consultants“Pilot four Paperthin-inspired skills in Pi Consultants”GitHub · Oct 20, 2026
- sudosubin/agents.nix“agent-skills.github.lilmgenius.paperthin: init at 0.17.7”GitHub · Oct 3, 2026
- Yeachan-Heo/gajae-code“research(ultragoal): explore Paperthin principles for bounded, evidence-driven execution”GitHub · Aug 29, 2026
The biggest 5 of 10 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 10
Talked about on GitHub (10 times).
On GitHub · 10
- Jul 26, 2026Paperthin 핵심 기능 도입 작업 지시서 — LowyShin/giip-fde-agent1 reaction
- Nov 6, 2026Refactor and Debloat skill — dragoscirjan/ai0 reactions
- Oct 20, 2026Pilot four Paperthin-inspired skills in Pi Consultants — tranhoangnguyen03/pi-consultants0 reactions · 1 comment
- Oct 3, 2026agent-skills.github.lilmgenius.paperthin: init at 0.17.7 — sudosubin/agents.nix0 reactions
- Aug 29, 2026research(ultragoal): explore Paperthin principles for bounded, evidence-driven execution — Yeachan-Heo/gajae-code0 reactions · 1 comment
5 more on GitHub
- Aug 26, 2026📝 https://github.com/LilMGenius/paperthin tool-study — adszzz11/study0 reactions
- Aug 26, 2026Track Codexy 1.6.0 lightweight skills and mechanical enforcement reduction — eunsoogi/codexy0 reactions · 10 comments
- Aug 26, 2026Record clean-room observations from the pinned research source — eunsoogi/codexy0 reactions · 3 comments
- Aug 26, 2026feat: add Paperthin-inspired artifact reflexes — BokEumEom/infrastructure-engineering-harness0 reactions · 1 comment
- Jun 21, 2026[skills.sh] Redirect LilMGenius/skills listings to LilMGenius/paperthin — vercel-labs/skills0 reactions · 1 comment
In this repository46 other files it gives its agents.
- AGENTS.mdAGENTS.md
- llms.txtllms.txt
- re0-importSkill
- re0-readmeSkill
- re0-upgradeSkill
- ssotize-localSkill
- ssotizeSkill
- backpropSkill
- catchupSkill
- nbaSkill
- paperthinSkill
- re0-loopSkill
- re0-memoSkill
- re0-planSkill
- re0-tutorialSkill
- re0-watchSkill
- re0-workflowSkill
- re0-workSkill
- aimSkill
- autobahnSkill
- crossthinkSkill
- debloatSkill
- dedashSkill
- dedotSkill
- deidSkill
- detoolSkill
- elonSkill
- factchkSkill
- hateSkill
- macrothinkSkill
- mandelaSkill
- modelchkSkill
- re0-decideSkill
- re0-gitSkill
- re0-mergeSkill
- re0-orderSkill
- re0-releaseSkill
- re0Skill
- re0-squashSkill
- re0-styleSkill
- readbackSkill
- scopechkSkill
- showerSkill
- sipSkill
- whychkSkill
- multithinkSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
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
- Distinctive: line 28
Test doubles inside tests are left alone.
- Distinctive: line 39
Every finding has its location, the evidence that it reaches the real path or its unverified mark, its class and its proposal.
- Distinctive: line 40
No file was changed without the human's approval.
- Distinctive: line 41
Every applied fix has a test that failed first.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Find candidates for a test double, a swallowed failure or a placeholder on the real code path with the bundled script, read each one, and propose the real dependency or an honest failure before anything is fixed.
Goal
A real code path runs what it claims to run: a success means the work happened, and a failure surfaces with its cause. The scope is what the human named: files, directories, a diff, or the change just made. The run never picks its own target.
The run reports each finding with its location, the evidence that it is reached from the real path, its class and its proposal; then, for each item the human approved, the test that failed first and the fix. A run whose scope holds no finding changes nothing and says so.
Workflow
- Split real paths from test paths first. Read the repository's test convention from its test directories, file naming rules and test configuration. A real path is code reached from an entry point (build output, an export, a handler, a CLI): trace it through imports and calls, including what dependency injection or a registry wires in. Code nothing reaches is dead, not a finding here; report it for a cleanup pass.
- List candidates. From this skill's folder run
node scripts/scan.mjs <paths...> [--test-glob <glob>]... [--json]over the scope, adding a--test-globfor each test path the repository's convention names beyond the defaults. It prints each candidate outside the test paths with its file, line, kind and evidence text;--jsonprints one JSON object. Exit codes: 0 no candidate, 3 candidates, 2 a usage error. An exit of 2 is a broken run: fix the command and run again. A name match is a lead, never a verdict. - Add the repository's own linter rules. When the repository already uses a linter carrying swallowed-failure rules (ruff BLE, S110 and S112, ESLint no-empty, Go errcheck), run those rules through the repository's own scripts or locally installed binaries at the version it declares, and add their hits to the candidates. Install no new tool.
- Read and classify each candidate. Class (a) is a test double on the real path. Class (b) is a false success: a catch that turns a failure into a success, logged or not, a fallback whose caller cannot tell it from the real result, or a gate on access, spending, deletion or a counted signal that lets the request through when the secret, dependency or input it checks is missing. Class (c) is a placeholder: an unfinished implementation the real path reaches. Class (d) is intended: a seam where the real implementation is chosen at runtime, a degradation the caller can see (a typed empty result, a flag, a documented status) and is designed to handle, an offline mode documented and off by default on the real path, or code a production build excludes. Keep (d) with its evidence. When reaching the real path cannot be confirmed, give the candidate its class and proposal and mark it unverified.
- Propose a fix for each (a), (b) and (c): the real dependency that should run, or an honest failure that surfaces the cause; for a gate that lets requests through, the honest failure is a denial. Never propose swapping one fake for another.
- Stop and report. Report the findings and their proposals, including any pattern the script missed, and end the run. The human approves by naming the items to fix; nothing else changes.
- Fix one approved item at a time. First write a test that fails on the fake, proving the real path runs or the failure surfaces; then fix the item and rerun the repository's checks.
Rules
- The scope is what the human named. Never widen it or choose a target on your own.
- The script owns the candidate patterns and the default test conventions; a pattern it missed is proposed as a script change with a test, under the same approval as a fix.
- Test doubles inside tests are left alone.
- A log followed by a rethrow at a boundary is an honest failure and stays.
- A fix replaces a fake with the real dependency or an honest failure, never with another fake.
- Nothing is fixed without the human's approval, and each fix has a test that failed first.
- A run with no finding changes nothing.
- Vocabulary for the doubles follows Gerard Meszaros's test double taxonomy (dummy, stub, spy, mock, fake) and Martin Fowler's "Mocks Aren't Stubs".
Verification
Before finishing, confirm:
- Every finding has its location, the evidence that it reaches the real path or its unverified mark, its class and its proposal.
- No file was changed without the human's approval.
- Every applied fix has a test that failed first.
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
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.

