/bet-on-it
Use when debugging or changing behavior based on an uncertain causal hypothesis that the next action can test.
$ npx -y skills add Lum1104/bet-on-it --skill bet-on-it --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/bet-on-it
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when debugging or changing behavior based on an uncertain causal hypothesis that the next action can test.
SKILL.md
bet-on-it.SKILL.mdname: bet-on-it
description: Use when debugging or changing behavior based on an uncertain causal hypothesis that the next action can test.
Bet On It
Make each action earn or lose confidence. Never rewrite a prediction after its result.
Record the bet
When an action depends on an uncertain causal explanation, record this in working notes or commentary—not a repository file:
Hypothesis: <current causal explanation>
Expected observation: <specific result expected from the next action>
Expected change: <files, state, metric, or behavior; none for observation-only steps>
Disproof: <result that would make this hypothesis untenable>
Use observable signals. One bet may cover coupled steps. Skip bets for mechanical work or settled requirements.
Run the smallest discriminating step
Choose the cheapest safe step that separates plausible alternatives. Prefer read-only observation or temporary instrumentation before a persistent edit. Preserve baselines; separate unrelated changes.
Settle the bet
After the action, preserve the original prediction and append:
Observed: <actual result, including unexpected changes>
Verdict: matched | partially matched | failed | inconclusive
Next action: <continue, refine, abandon, revert, or gather a better signal>
Apply the verdicts consistently:
- **Matched**: Expected results occurred and disproof did not. This raises confidence but does not prove causality when rivals predict the same result.
- **Partially matched**: Some predictions held; narrow or revise the hypothesis.
- **Failed**: A valid discriminator produced disproof or failed a required prediction. Abandon or revise.
- **Inconclusive**: The step or measurement could not distinguish alternatives. Do not count it as support.
Revert speculative changes after a failed hypothesis when they lack independent justification. To keep one, state the new reason and test it under a new prediction.
Example
For a duplicate checkout request, Bet 1 predicts that instrumentation will show two client handler invocations; one invocation with two requests disproves it. Make no behavior change.
Only if Bet 1 matches, Bet 2 predicts that removing the duplicate binding in `Checkout.tsx` will reduce invocations and requests from two to one; two requests after one invocation disproves it.
If Bet 1 fails, do not make or retain the client fix. Form a retry or idempotency hypothesis.
Read more
name: bet-on-it description: Use when debugging or changing behavior based on an uncertain causal hypothesis that the next action can test.
Bet On It
Make each action earn or lose confidence. Never rewrite a prediction after its result.
Record the bet
When an action depends on an uncertain causal explanation, record this in working notes or commentary—not a repository file:
Hypothesis: <current causal explanation> Expected observation: <specific result expected from the next action> Expected change: <files, state, metric, or behavior; none for observation-only steps> Disproof: <result that would make this hypothesis untenable>
Use observable signals. One bet may cover coupled steps. Skip bets for mechanical work or settled requirements.
Run the smallest discriminating step
Choose the cheapest safe step that separates plausible alternatives. Prefer read-only observation or temporary instrumentation before a persistent edit. Preserve baselines; separate unrelated changes.
Settle the bet
After the action, preserve the original prediction and append:
Observed: <actual result, including unexpected changes> Verdict: matched | partially matched | failed | inconclusive Next action: <continue, refine, abandon, revert, or gather a better signal>
Apply the verdicts consistently:
- **Matched**: Expected results occurred and disproof did not. This raises confidence but does not prove causality when rivals predict the same result.
- **Partially matched**: Some predictions held; narrow or revise the hypothesis.
- **Failed**: A valid discriminator produced disproof or failed a required prediction. Abandon or revise.
- **Inconclusive**: The step or measurement could not distinguish alternatives. Do not count it as support.
Revert speculative changes after a failed hypothesis when they lack independent justification. To keep one, state the new reason and test it under a new prediction.
Example
For a duplicate checkout request, Bet 1 predicts that instrumentation will show two client handler invocations; one invocation with two requests disproves it. Make no behavior change.
Only if Bet 1 matches, Bet 2 predicts that removing the duplicate binding in `Checkout.tsx` will reduce invocations and requests from two to one; two requests after one invocation disproves it.
If Bet 1 fails, do not make or retain the client fix. Form a retry or idempotency hypothesis.
Your agents change the code, then explain why. This skill makes them bet on the result first.