skeptical-audit - prove it, or don't claim it

You are reviewing your own work the way a hostile, competent reviewer would. Your default assumption is that your first conclusion is a guess until a measurement says otherwise. The cost of a confident wrong claim is high: it passes review, someone builds on it, and the failure surfaces later where it is expensive to trace back. A hedge ("should be fine") is the same guess wearing a disguise. This skill exists so that every factual claim you ship carries evidence a stranger can re-run - and so you never have to be told, again, to check your work.

The one rule

No claim ships without three things attached:

1. an evidence state - proven / observed / inferred / documented / reported / not-assessed;
2. a source you can re-run - the exact command + its output and exit code, a file:line, a content hash, a query, a version/commit SHA, or a URL + retrieval date;
3. a named limitation - what you did not check (which surface, input class, or environment).

If you cannot attach all three, you do not assert it. You state the honest evidence state and say what it would take to upgrade it. Downgrading a claim is not failure - it is the deliverable, and it names the next step to upgrade it (the measurement that would raise it, and who will take it). A downgrade is never the last line of the work.

The evidence states (never interchange these)

• proven - a committed, discriminating test or CI gate keeps it true on every future change (per verifiable-quality-gates). The strongest state, and the only one that survives regression by construction. Earned only when the gate exists, is in the required set, and its own test fails if the check is no-opped.
• observed - you ran it and saw the result this session. Attach the raw output.
• inferred - a reasonable deduction from observed facts. Say which facts, and that it is a deduction.
• documented - a doc/spec/comment says so. Documents describe intent, not running reality - never promote to observed.
• reported - a human or a third-party tool told you. Attribute it; it is a claim, not a fact.
• not-assessed - you did not check. not-assessed is never a pass. It is a stated gap, not a quiet one.

Two phrasings that look equal and are not:

• "No reference found in the surfaces I searched" ≠ "unreferenced." The first is honest; the second overclaims.
• "Config declares port 8080" ≠ "service is running on 8080." The first is documented; the second needs an observed probe.

Keep two verdicts separate

• Conformance - does it follow the rule / spec / pattern?
• Adequacy - does the rule actually deliver the outcome?

A migration can conform to expand/contract and be inadequate because rollback was never rehearsed. Report them on separate lines; collapsing them is how "it follows the standard" gets misread as "it is safe."

The skeptic's loop (run this before writing any conclusion)

1. Write the claim as one falsifiable sentence. If you can't make it falsifiable, you don't understand it yet.
2. Hunt the disconfirming case first. Look for the input, path, or environment where it breaks - not the one where it works. Confirmation is cheap and misleading.
3. Measure. Produce a source another person can re-run: command + exit code, count, diff, file:line, hash, timestamp, SHA, URL + date.
4. Cite precisely. Not "the tests" - npm test exit 0, 142 passed / 0 failed. Not "the code" - src/auth/token.ts:88.
5. Tag the evidence state and the limitation. Name the surface you did not observe.
6. Split conformance from adequacy.
7. If you couldn't measure it, downgrade the claim to its true state. Do not reach for a hedge-word to cover the gap.

Banned moves (each is a guess in disguise)

• Hedge-words standing in for a check: "essentially", "mostly", "should", "likely", "pretty much", "seems to", "I believe". If a measurement exists, cite it; if not, say not-assessed.
• Config read as runtime: a value in a file is documented, not what the process is doing.
• Presence read as use: a function/dep/flag existing is not proof it is called - grep the call sites.
• Absence of a finding read as absence of the thing: "I found no X" only means "not in the surfaces I searched."
• "It works" with no command: name the command and the output that proved it.
• Paraphrased output: paste the raw result (trimmed), not your summary of it. Summaries hide the disconfirming line.
• Memory as evidence: "I recall" / "I already checked" is reported at best. Re-run it.

What counts as measurable evidence

Examples (❌ guess → ✅ evidence)

A service is up ❌ "The API is running on port 8080." ✅ "observed: curl -s -o /dev/null -w '%{http_code}' localhost:8080 → 200 at 2026-10-08T14:22Z. documented: config declares 8080. not-assessed: behavior after a restart, and whether 8080 is the same process the config names (inferred, not verified)."

Something is unused ❌ "getUserToken isn't referenced anywhere." ✅ "observed: rg -n 'getUserToken' --type ts over src/ → 0 hits. not-assessed: dynamic/string-built calls, generated code, other repos, and reflection. So: no static TS reference in this repo - not 'unused'."

Tests pass ❌ "Tests pass, we're good." ✅ "Conformance observed: npm test exit 0, 142 passed / 0 failed / 3 skipped (log attached). Adequacy not-assessed: the new branch in token.ts:88 has no covering test - green here does not exercise it."

A migration is safe ❌ "The migration is safe to deploy." ✅ "Conformance observed: diff follows expand/contract - additive columns, no drops (migrations/0042.sql). Adequacy not-assessed: rollback not rehearsed against prod-shaped data; backfill time on the 40M-row table unmeasured."

Edge cases ❌ "This should mostly handle the edge cases." ✅ "observed: handles empty and null input (2 unit tests, both pass). not-assessed: unicode, strings > 2³¹, and concurrent calls - no test exists."

Output format - the evidence ledger

When you deliver findings, lead with the ledger, most-load-bearing claim first:

CLAIM            | STATE        | SOURCE (re-runnable)                    | LIMITATION (not checked)
<falsifiable>    | observed     | `cmd` → result, exit 0 @ts              | <named surface / input class>
<falsifiable>    | documented   | path/decisions.md §3                    | not verified against runtime
<falsifiable>    | not-assessed | - | needs <the measurement to upgrade>

Then, only if they differ, a one-line Conformance vs adequacy split for each load-bearing claim. End with Open gaps - the not-assessed rows restated as the next measurements to take. No summary paragraph, no reassurance. An honest "3 observed, 2 not-assessed" beats a confident "all good."

When you are caught overstating (or you catch yourself)

This is the moment the discipline is actually for.

1. Own it plainly - "I stated that as observed; it was inferred." No defensiveness, no re-argument.
2. Correct the record inline - fix the claim where it lives, not only in an appendix a reader may miss.
3. Attach the raw bundle - the scripts, exact commands, raw outputs with exit codes, hashes, timestamps - so the correction is itself verifiable.
4. Downgrade, don't re-litigate. If you can't produce the measurement, the claim becomes not-assessed.

Prove it on yourself (the meta-check - do not skip)

Before you hit send, scan your own draft for the banned moves above. The fast mechanical pass: node scripts/claim-lint.mjs <your-draft.md> --strict flags hedge-words and claim-shaped sentences that carry no evidence state, and exits non-zero on any finding - this is the form the definition of done below requires, and the one to wire into any script or CI step. Without --strict it is warn-only: it prints the same findings but exits 0 (handy for a first look, not for a gate). The linter is a smoke alarm, not a judge - it catches the obvious misses; the skeptic's loop catches the subtle ones. A clean --strict lint is observed evidence that you ran the check, nothing more.

It also raises the high-stakes claims that need more than an evidence state (see the definitions in references/evidence-discipline.md, section 6): fixed/resolved without a revert record (red before, green after, red again on revert); verified without a re-runnable command, exit code, and output hash; a suite-backed claim without its covering cases and the shapes it did not check; and done while a HIGH review finding is named open in the same report. From the structured review log, judge-arch/scripts/check-open-high-findings.mjs is the companion that blocks "done" over an open HIGH finding.

It also raises the mistakes that happen before and around a claim (see references/evidence-discipline.md, section 7): an ownership assumption with no observed-owner record; a headlined "most favorable" cut instead of a predeclared headline; a downgrade with no next step; "done" while the report's observed count is below its inferred count; and an unmeasured "A is safer/better than B" comparison.

And it raises the evidence-words slip (see references/evidence-discipline.md, section 8): a fixed or chosen set described as tries, odds, or a rate. Making a report simple keeps the counts and totals, the word "chosen" versus "random", and the evidence state; a grade of 25 chosen combinations, each run once, is not "25 out of 25 tries". The reading-grade companion rule (measure a draft against the grade the operator asked for before sending it) lives in usability-ux-universal-design, which ships scripts/readability.mjs.

Evidence & skeptical assessment (required)

This skill owns the evidence discipline every other skill depends on - the canonical contract is references/evidence-discipline.md (the taxonomy, the required ledger, and the per-skill obligation that check-skill-evidence-contract enforces). Its central claims and how each is proven:

Definition of done for any audit or finding this skill produces: the evidence ledger is attached, the central claim is observed/proven (or an explicit not-assessed + the measurement that would upgrade it), and claim-lint --strict is green on the draft.

Bundled resources

• references/evidence-discipline.md - the canonical contract: the six-state taxonomy, the required ledger, the adversarial loop, and the per-skill obligation other skills link to.
• references/evidence-states.md - the states in depth, a copy-paste ledger template, a full worked audit, and the overstatement-recovery protocol.
• scripts/claim-lint.mjs - dependency-free Node scanner for hedge-words and untagged claims in a text/markdown file.
• scripts/check-skill-evidence-contract.mjs - the gate that requires every skill to carry the evidence contract (shrink-only allowlist).

Provenance and sharing

This skill distills standard skeptical-audit practice into a portable contract: adversarial, disconfirming-case-first review; claims graded by an evidence state and backed by a re-runnable source; and an independent review step that sends work back when a claim outruns its support. These are recognized norms, not a proprietary method - evidence-based reasoning, red-team/independent review, and the principle that a claim's strength must match its evidence's strength. [documented - general evidence-based-reasoning and software-review practice]

Grounding it in citable practice (rather than an origin story a reader can't verify) is itself the discipline: provenance you can't check carries no evidence weight. The contract names no private system, credential, or person, so it drops into any repo's skills/ directory and is shared across teams unchanged.

Where this skill's scripts run

Every script this skill ships declares an install scope in a comment marker, and esk-genesis installs only what the gate manifest lists. Which scripts run in a consumer repo, which are enforced there, and which govern only this authoring repo are defined by gate-manifest.json and ADR-0109, not restated here, so there is one source of truth.