Finding evidence for a plausible fix is easy. Finding evidence against it is what makes the claim trustworthy.
prove-me-wrong names what would disprove a claim, considers a competing explanation, and runs the cheapest realistic test that could prove the fix wrong.
Use bet-on-it before an action to commit to a prediction. Use prove-me-wrong once a claim or fix is favored to design an attack that could defeat it.
Before / After
Without prove-me-wrong
The duplicate-order bug came from double-clicks. I debounced the button, the browser test passes, and the issue is fixed.
The test confirms the path the patch was designed to improve. It does not challenge the explanation.
With prove-me-wrong
Claim: Debouncing the button prevents duplicate durable orders.
Smallest falsifier: One logical checkout still creates two order IDs.
Strongest plausible competitor: A retried payment callback reaches non-idempotent order creation.
Cheapest safe attack: Send one checkout with a fixed idempotency key,
replay the callback, and count authoritative order records.
If the replay creates two orders, the claim is falsified. If callback visibility is unavailable, the result is unavailable—not support. The goal is not more tests; it is one realistic attack that can make the favored story lose.
Install
Install with the Skills CLI:
npx skills add Lum1104/prove-me-wrong
Install globally for all projects:
npx skills add Lum1104/prove-me-wrong -g
The repository's root SKILL.md is directly discoverable. The skill adds no runtime, service, or testing framework.
Use it
In agents that automatically select installed skills, the description can trigger it when a leading diagnosis or fix has initial support. Invoke it explicitly when a plausible fix is starting to feel proven:
Use the prove-me-wrong skill on my cache-key hypothesis.
Use the prove-me-wrong skill before we accept this race-condition fix.
Use the prove-me-wrong skill to find a realistic case where this patch still fails.
In Codex, use $prove-me-wrong. In Claude Code, use /prove-me-wrong. Invocation syntax may vary in other agents.
Use it when:
- a leading explanation still has a plausible competitor;
- a bug is intermittent or timing-sensitive;
- a nontrivial fix passes only its happy path;
- a regression explanation is plausible but unchallenged;
- being wrong would preserve a real user-facing failure.
Skip it for typos and directly observable mechanical edits.
The falsification loop
Claim
↓
Smallest falsifier
↓
Strongest plausible competitor
↓
Cheapest safe attack
↓
Reject, narrow, survive, or remain unverified
If the falsifier occurs, the agent abandons or narrows the claim and removes speculative edits that have lost their justification. If the claim survives, the report says exactly which attack it survived—not that the theory was proved forever.
Attack the completed fix
For a completed nontrivial fix, the agent constructs one realistic residual failure from the same workflow:
- a boundary the patch does not cross;
- a state transition it assumes away;
- a retry, concurrency, or ordering path;
- an integration seam or surviving competitor.
It avoids arbitrary edge-case generation. The counterexample must be plausible enough to change confidence in the actual task.
What this does not prove
prove-me-wrong is targeted falsification, not exhaustive verification. It cannot:
- prove correctness for every input or deployment;
- turn an ambiguous observation into support;
- run experiments in systems the agent cannot access;
- replace end-to-end outcome verification;
- justify keeping a speculative edit after its hypothesis fails.
Bet first, then attack
bet-on-it and prove-me-wrong may intentionally activate together:
| Skill | Primary question |
|---|
bet-on-it | What do I predict before the next causally uncertain action? |
prove-me-wrong | What observation or competitor could defeat the claim I now favor? |
For final workflow evidence, use no-vibes. For high-impact execution, use red-button. Each skill remains independently useful.
Repository contents
License
MIT
@lum1104