Audit whether every check in the repo can tell "passed" apart from "never ran" — empty input reported as clean, filters that narrow the verdict as well as the output, exit codes read where the artifact is the evidence, skipped steps reported as passed, and reports with no denominator. Use for "the lint says clean but the bug shipped", "did that check actually run", "the test filter matched nothing", "green build, broken tree", "why did nothing get flagged", or as part of /opus-pocus. Read-onl...
Scanned 9/6/2026
Install to Claude Code
npx -y skills add Totes-MickGOATs/opus-pocus --skill nihil-revelio --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Nihil Revelio?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/totes-mickgoats-nihil-revelio)More formats (shields.io, HTML) on the badges page.
---
name: nihil-revelio
description: Audit whether every check in the repo can tell "passed" apart from "never ran" — empty input reported as clean, filters that narrow the verdict as well as the output, exit codes read where the artifact is the evidence, skipped steps reported as passed, and reports with no denominator. Use for "the lint says clean but the bug shipped", "did that check actually run", "the test filter matched nothing", "green build, broken tree", "why did nothing get flagged", or as part of /opus-pocus. Read-only; prescribes distinct degraded verdicts per finding. NOT for whether an artifact is wired at all (→ priori-incantato). NOT for guards that block too much (→ alohomora).
---
# 🐉 Nihil Revelio
> *"It scanned nothing. It said 'clean.' Those are different words."*
**An unexercised check is blind, not clean.** A check that cannot distinguish *"I looked and
found nothing"* from *"I never looked"* reports the same success for both, and the second one
is the state that ships defects. This is the most expensive class of automation defect because
it inverts the tool's purpose: the green verdict is not merely uninformative, it is actively
misleading, and it is trusted precisely when it should not be.
## What to scan
- Every lint, gate, verifier and test-runner wrapper the repo carries
- Their verdict logic: what they print, what they exit with, and how the two relate
- Every caller that reads one of those verdicts — a caller reading an exit code where the
artifact is the evidence is half the defect
- Filter and selector arguments, and what a non-matching filter produces
- Test suites for the checks themselves: is each verdict state exercised by a case?
**Vendor tools are out of scope; their invocation is in scope.** You cannot add a verdict state to
`eslint`, `pytest`, `tsc` or `go test` — what you own is the line that calls them and the step that
reads the result, so audit that. On a repo whose checks are all vendor tools, the instances of this
class look like:
- a CI step whose file glob matched nothing and exited 0 (`eslint $CHANGED` with `$CHANGED` empty)
- a test run that collected **zero** tests and reported success — a typo'd `pytest -k` expression,
`go test ./internal/...` on a package that moved, a Jest `testPathPattern` matching nothing
- a `continue-on-error: true` step whose failure the rollup then reports as green
- a coverage gate reading an artifact that was never written
Prescribe the guard on the **caller**: assert a non-empty input set before invoking, assert a
non-zero collected-test count after (`pytest --co -q | tail -1`, `jest --listTests | wc -l`), and
assert the results file exists and is newer than its inputs. If the repo's only checks are vendor
tools invoked with no such assertion, that is **one** finding, not seven.
## Anti-patterns to find
1. **Empty input treated as success.** A check handed no files reports clean, because "no
findings" and "nothing examined" share a code path. The degenerate case is the common case
in CI, where a bad path expression silently yields an empty set.
2. **A filter that narrows the verdict, not just the output.** Passing a filter restricts what
is examined *and* what is judged, so a non-matching filter prints clean and exits zero with
real failures sitting in the log.
3. **Exit-code reading where the artifact is the evidence.** A green exit with a results file
that is missing, empty, stale, truncated or unparseable is not a pass. The process
succeeding and the work being verified are different claims.
4. **A skipped step reported as a passed step.** Skips are legitimate — a skip counted as a pass
is not. The rollup absorbs it and the coverage number lies.
5. **Fallback-on-no-input.** A check handed an empty list silently widens to scan everything, or
the current directory, or a default set. That is a different measurement wearing the same
verdict, and it is indistinguishable downstream.
6. **No denominator.** A report with no "N scanned" leaves the reader unable to separate
coverage from vacuum. Every verdict needs the size of what produced it.
7. **Success indistinguishable from failure.** A probe returning the same value for *healthy*
and *unreachable*; a query whose "no results" and "could not connect" render identically.
The consumer cannot behave correctly on an ambiguous signal, however carefully it is written.
## Fix prescriptions
| Finding class | Fix |
|---|---|
| Empty input as success | Make "could not tell" a distinct, loud third state — never folded into pass. `SCANNED NOTHING` / `DEGRADED` / `CANNOT VERIFY` as first-class verdicts with their own exit codes |
| Verdict-narrowing filter | Forbid filters on verification runs, or make a non-matching filter an error rather than an empty pass. Document that the filter narrows output only |
| Exit-code reading | Assert the artifact, not the call: the results file exists, parses, is newer than its inputs, and contains the expected case count |
| Skip counted as pass | Report skips in their own column and name each one with its reason. A rollup that hides skips is a rollup that lies |
| Fallback-on-no-input | Refuse and report, rather than widening. A widened scan is a different measurement and must not inherit the narrow one's verdict |
| No denominator | Always print what was examined alongside what was found — "0 findings across 0 files" is a wholly different sentence from "0 findings across 412 files" |
| Ambiguous states | Give every distinguishable outcome its own verdict string and exit code; add a failing-first test per state so each one is exercised, because an untested verdict path is itself an unexercised check |
## Bounds
- Scope: the repo's own lints, gates, verifiers and test-runner wrappers, and the callers that read their verdicts — including the CI steps and scripts that invoke vendor tools. Not the vendor tools' own internals, not the application's test suite, and not another plugin's checks.
- Cap: 15 findings, ranked by whether a false clean is reachable today with a plausible input.
- Done when each check's verdict states have been enumerated once.
- Quote once, at read time; mark anything you cannot re-confirm `UNVERIFIED` rather than re-reading to check yourself.
- See `skills/opus-pocus/references/casting-safety.md` for the full rules.
## Report format
Per check: `path` · verdict states it can emit · states it *cannot* distinguish · the concrete
input that produces a false clean (an empty file list, a non-matching filter, a missing results
file) · prescription. Lead with the count of checks that can produce a false clean today, against
the total examined. `SCANNED NOTHING` if no checks were found — and note that this pass reporting
"clean" without a denominator would be its own first finding.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!