bet-on-it

Your agents change the code, then explain why.

This skill makes them bet on the result first.

Install · Before / After · How it works · Read the skill

Agents can explain almost any result after seeing it.

bet-on-it records the hypothesis, expected result, and losing condition before an action that depends on an uncertain causal explanation. After the experiment, it compares the observation with the prediction and drops unsupported changes.

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.

Install

Install with the Skills CLI:

npx skills add Lum1104/bet-on-it

Install globally for all projects:

npx skills add Lum1104/bet-on-it -g

Then invoke it when the next diagnostic or behavior-changing step depends on an uncertain cause:

Use $bet-on-it to debug these duplicate checkout requests.

Before / after

Before

The duplicate requests were probably caused by a React effect. I changed its dependencies. Tests pass, so that was likely the issue.

The explanation appeared after the edit. There is no record of what the agent expected to observe, and the change can remain even if the duplicate originated on the server.

After

Bet 1
Hypothesis: A React effect binds the submit handler twice after rerender.
Expected observation: Instrumentation records two handler calls per click.
Expected change: none; this step only observes the current path.
Disproof: One client call still produces two server writes.

Instrumentation records one client call and two server writes. Bet 1 failed, so the agent does not make the effect edit. It forms a retry/idempotency hypothesis next. Only a matched Bet 1 would justify Bet 2 predicting the result of correcting the binding.

The core mechanism

1. Record the bet

When the next action depends on an uncertain causal explanation, write four short fields:

Hypothesis: <current causal explanation>
Expected observation: <specific result expected next>
Expected change: <files, state, metric, or behavior; none for observation-only steps>
Disproof: <result that would make the hypothesis untenable>

A useful prediction names a value, error, event, diff, or behavior. “This should help” is not a bet.

2. Run the smallest discriminating step

Choose the cheapest safe action that separates the current hypothesis from a plausible alternative. Prefer read-only observation or temporary instrumentation before a persistent edit. Avoid bundling unrelated changes.

3. Settle it without rewriting it

Preserve the original prediction and append:

Observed: <what actually happened>
Verdict: matched | partially matched | failed | inconclusive
Next action: <continue, refine, abandon, revert, or gather a better signal>

A small performance example

Hypothesis: Repeated JSON parsing dominates request latency.
Expected observation: A profile attributes more than half of the slow path to JSON.parse.
Expected change: none; this step only profiles the baseline.
Disproof: Parsing is a minor sample in the slow path.

If the profile instead shows database wait time, the parsing optimization has no justification. Only a matched profile bet should lead to a second bet predicting how caching changes p95 latency.

Use it for

• Debugging where several causes could explain the same symptom.
• Performance work with measurable expected movement.
• Nontrivial fixes justified by a suspected causal mechanism.
• Speculative implementation changes that may need to be reverted.
• Investigations where a persuasive post-hoc story could hide a failed idea.

Explicit prompts:

Use $bet-on-it before changing this cache invalidation logic.
Use $bet-on-it to make the next debugging step discriminate between two causes.
Use $bet-on-it and revert the edit if its prediction fails.

Non-goals and limits

• It is not ceremony for formatting, renaming, or other mechanical edits.
• A matched prediction raises confidence; it does not prove a hypothesis uniquely true.
• It does not require a risky experiment. Safety and permission boundaries still control the action.
• An inconclusive result is allowed. The skill prevents it from being counted as confirmation.
• Predictions are short working records, not permanent design documents.

The skill

The complete agent-facing protocol lives in SKILL.md. The repository is intentionally instruction-only: no framework, service, or runtime dependency.

Related skills

Each repository is standalone. Combine them only when their failure modes overlap.

License

MIT © 2026 Lum1104