hypothesis-falsification
Skill0 starsChanged 5 months agoMITView on GitHub
Tests hypotheses by trying to disprove them, designing the cheapest experiment that could kill the idea fastest. Use when debugging a mysterious bug, validating a root-cause theory, evaluating a risky assumption, or whenever a belief drives a costly decision and could be wrong.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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 19
Prefer tests that *eliminate* over tests that *confirm* — eliminating a cause is certain.
- Distinctive: line 27
Unfalsifiable patching: if every failed prediction spawns a new auxiliary excuse ("it's the DB, except when it's the cache, except..."), …
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
Hypothesis Falsification
Seek the evidence that would prove you wrong, not the evidence that comforts you. A hypothesis that forbids nothing explains nothing; the value of a theory is what it rules out.
State the hypothesis so it can die
- Make it falsifiable: phrase it as a prediction with a clear failing observation. "The slowness is the DB" is untestable; "if it's the DB, query latency p99 > 200ms during the spike" can be killed.
- Enumerate competing hypotheses: the bug has several plausible causes. List them all; the goal is to discriminate, not confirm the first one.
- Find the discriminating test: design the single observation whose outcome splits the hypothesis space the most (maximize information gain — a test that all hypotheses predict identically is worthless).
The cheapest kill first
- Rank candidate tests by
(information gained) / (cost to run). A 30-second log check that eliminates 3 of 5 hypotheses beats a 2-hour reproduction that confirms 1. - Prefer tests that eliminate over tests that confirm — eliminating a cause is certain; confirming is always provisional (some other cause could produce the same symptom).
- Bisect the hypothesis space (binary search): each test should roughly halve the remaining possibilities.
Adversarial validation (turn it on your own theory)
- Confirmation bias: are you only looking where you expect to find it? Actively seek the observation that contradicts your favored cause.
- Coincidence vs cause: the thing you changed correlates with the symptom — but did you establish the mechanism, or just temporal proximity? Correlation in a single sample is nearly worthless.
- The fix that "worked": did your change fix it, or did the load/condition that triggered it simply pass? Reproduce on demand before claiming a fix.
- Unfalsifiable patching: if every failed prediction spawns a new auxiliary excuse ("it's the DB, except when it's the cache, except..."), the theory is unfalsifiable — discard it.
Non-obvious risks
- Absence of evidence is evidence of absence only if you looked where the evidence would be; a test that couldn't have detected the cause proves nothing.
- The most dangerous hypothesis is the one everyone already believes — it gets the least scrutiny and is tested last.
- Multiple causes can coexist; fixing one and seeing partial improvement can hide a second.
Output structure
Deliver: the falsifiable hypothesis with its killing observation, the full set of competing hypotheses, the discriminating tests ranked by information-per-cost, the result of each test and which hypotheses it eliminated, and the surviving cause confirmed by a reproducible mechanism — not just correlation.
In this repository29 other files it gives its agents.
- adversarial-code-reviewSkill
- api-contract-designSkill
- attack-surface-mappingSkill
- authn-authz-design-reviewSkill
- benchmark-designSkill
- capacity-scalability-planningSkill
- concurrency-race-analysisSkill
- data-consistency-modelingSkill
- data-exfiltration-analysisSkill
- distributed-consensus-designSkill
- error-handling-architectureSkill
- event-driven-architectureSkill
- experiment-designSkill
- incident-rca-postmortemSkill
- legacy-refactoring-strategySkill
- literature-synthesisSkill
- metrics-designSkill
- multi-layer-caching-strategySkill
- mvp-scope-cuttingSkill
- performance-profilingSkill
- rate-limiting-designSkill
- requirements-disambiguationSkill
- secrets-management-auditSkill
- statistical-validity-analysisSkill
- supply-chain-risk-analysisSkill
- system-decomposition-synthesisSkill
- threat-modelingSkill
- tradeoff-decision-frameworkSkill
- user-failure-mode-mappingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

