Falsify the Problem

# falsify-the-problem

> Falsify the problem before solving it.

Answer **Are we solving the right problem?** Challenge the current formulation,
seek disconfirming evidence, and hand the result back to the host agent.
Do not design or implement the solution inside this skill.
Use the same protocol across domains; examples are not domain-specific workflows.

## 1. Decide whether to enter

- Explicit invocation of `falsify-the-problem`: always enter. Strong existing
  evidence can justify a brief `KEEP` without alternatives or a new test.
- Automatic activation: require BOTH meaningful formulation uncertainty AND
  non-trivial intervention cost or risk. Neither alone is enough.
- Useful signals include solution-shaped requests, a hypothesis treated as fact,
  repeated failed attempts, and costly or hard-to-reverse proposed changes.
  Signals are reasons to check the gate, not unconditional triggers.
- Usually do not auto-activate for a verified diagnosis, obvious syntax or
  compilation error, typo, translation, formatting, mechanical transformation,
  deterministic local edit, or very cheap reversible intervention.
- Mere logical possibility of another explanation is insufficient.

`BYPASS` is an activation decision, never an evidence verdict. When bypassing,
leave the original task with the host; do not manufacture an adversarial report.
If explicitly invoked on a supported diagnosis, use `KEEP`, not `BYPASS`.

## 2. Separate the claims and preserve their sources