Assumption Rigor Audit Skill

What this skill changes vs. default behavior

By default, Claude accepts validation at face value — "we ran a survey and users liked it, so it's validated" passes without challenge. It rarely asks whether the riskiest assumption was the one tested, whether the method was strong enough for the decision it's meant to support, whether "would you use this?" answers were mistaken for evidence, whether success was defined before the test, or whether the sample was big enough to mean anything. This audit forces four things: every finding names the violated principle; the decision the test is meant to support is the unit of judgment (rigor scales to what's at stake); evidence claims are tested for signal vs. noise; and findings come severity-rated by decision damage with a concrete fix.

This is an evaluative skill: it auto-runs whenever a validation plan, experiment, discovery approach, or a "we validated…" claim is being reviewed — and as the validation step after pm-assumption-testing produces a test plan.

Scope discipline. When invoked directly (the user named this audit), review only this concern — don't pull in sibling audits. It runs alongside other lenses only when the pm-product-review orchestrator or a generative skill calls it under docs/orchestration-policy.md, where it sits in the always-relevant PM lens — auto-runs. Explicit scope always wins.

The framework — what to check and what a violation looks like

1. The riskiest assumption was tested — not the comfortable one

Assumptions should be mapped on importance × certainty; the high-importance / low-certainty ones (the leap-of-faith beliefs) carry the risk and get tested first. Testing everything indiscriminately, or testing what's easy, is wasted motion.

Flag when: the load-bearing assumption ("users will pay for this," "this is even a problem") is never named or never tested while easy/safe ones are; "we're testing everything" with no prioritization; the idea was tested but the beliefs the idea depends on weren't.