agentleFS
LilMGeniusLilMGenius/paperthin/skills/depth/demock/SKILL.md

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

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 1 mentionJul 2026: 1 mentionAug 2026: 5 mentionsSep 2026: 0 mentionsOct 2026: 2 mentionsNov 2026: 1 mention
Dec 2025Jun 2026Nov 2026
Mentions a month of the LilMGenius/paperthin repository that our weekly crawl found: only 10 in all, so this is a hint, not a trend. There is no adoption data for this file yet.

Who's talking about LilMGenius/paperthin

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

5 more on GitHub

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
  1. Distinctive:

    Test doubles inside tests are left alone.

    line 28
  2. Distinctive:

    Every finding has its location, the evidence that it reaches the real path or its unverified mark, its class and its proposal.

    line 39
  3. Distinctive:

    No file was changed without the human's approval.

    line 40
  4. Distinctive:

    Every applied fix has a test that failed first.

    line 41

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. 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.
  2. List candidates. From this skill's folder run node scripts/scan.mjs <paths...> [--test-glob <glob>]... [--json] over the scope, adding a --test-glob for 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; --json prints 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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:

  1. Every finding has its location, the evidence that it reaches the real path or its unverified mark, its class and its proposal.
  2. No file was changed without the human's approval.
  3. Every applied fix has a test that failed first.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.