brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Use when a leading diagnosis or nontrivial fix has initial support and needs one adversarial counterexample before acceptance.
Claude Code
$ npx -y skills add Lum1104/prove-me-wrong --skill prove-me-wrong --agent claude-code
Codex
$ npx skills add Lum1104/prove-me-wrong --skill prove-me-wrong -a codex -y
Cursor
$ npx skills add Lum1104/prove-me-wrong --skill prove-me-wrong -a cursor -y
Gemini CLI
$ npx skills add Lum1104/prove-me-wrong --skill prove-me-wrong -a gemini-cli -y
GitHub Copilot
$ npx skills add Lum1104/prove-me-wrong --skill prove-me-wrong -a github-copilot -y
OpenCode
$ npx skills add Lum1104/prove-me-wrong --skill prove-me-wrong -a opencode -y
Windsurf
$ npx skills add Lum1104/prove-me-wrong --skill prove-me-wrong -a windsurf -y
name: prove-me-wrong description: Use when a leading diagnosis or nontrivial fix has initial support and needs one adversarial counterexample before acceptance.
> Your agent has a theory. Make it try to kill it.
Use this at the commitment point: a leading claim is about to drive a substantial fix or be declared correct. It is not a prediction log for debugging steps. Skip mechanical edits.
Keep the card to four lines:
Claim: <specific causal explanation or behavior the fix guarantees> Smallest falsifier: <one observable result that contradicts the claim> Strongest plausible competitor: <an alternative that fits known facts> Cheapest safe attack: <a controlled check that can expose the falsifier>
Make the claim narrow and observable. Choose a credible competitor with a different prediction.
The attack must exercise the conditions under which the claim predicts an outcome. Missing the relevant path or state is inconclusive, not falsification.
Run one realistic controlled counterexample before accepting the claim:
1. Preserve the baseline and change only the variable that distinguishes the claim from its competitor. 2. Prefer a focused reproduction, test, query, log, toggle, or temporary instrumentation over a broad rewrite. 3. Record observation separately from interpretation, then remove temporary instrumentation.
For a completed fix, construct the counterexample within the requested workflow. Derive it from a boundary, state transition, concurrency path, integration seam, or surviving competitor—not an arbitrary edge case. When practical, show a regression test failing without the fix and passing with it.
Stop after a decisive falsifier. Otherwise stop after the strongest cheap realistic attack when further checks are costlier, outside scope, or unavailable. Add attacks only when the stakes justify safe, authorized work.
Revert speculative edits justified only by a falsified claim. Preserve user work and independently justified improvements; passing tests alone do not justify an edit.
Completed-fix example:
Claim: A unique key makes job execution idempotent. Attack: Crash after the external send but before recording completion, then retry. Observation: The retry sends the external action twice. Verdict: Falsified; uniqueness prevents duplicate rows, not duplicate side effects.
Report only:
Attack: <counterexample attempted> Observation: <what occurred> Verdict: <falsified | survived | inconclusive | unavailable> Residual risk: <important path not exercised, or none identified>
Your agents have a theory. This skill makes them ask, “What would prove me wrong?”
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.