Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Diagnoses a failure with parallel rival-hypothesis testing — multiple read-only subagents test distinct explanations in parallel, then rank by evidence weight while keeping losing rivals visible so the root cause is found honestly, not just plausibly. Make sure to use this skill whenever the user reports something broken with an unclear cause — "tests fail", "test is failing", "X doesn't work", "Y crashes", "why is Z happening", "investigate this bug", "what's causing this", "the bug is unclear"
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-07 | ✗→✓ | ▲ Improved | -22% | 0% |
| case-09 | ✗→✓ | ▲ Improved | -48% | 0% |
| case-11 | ✗→✓ | ▲ Improved | -31% | 0% |
| case-14 | ✗→✓ | ▲ Improved | -34% | 0% |
| case-18 | ✗→✓ | ▲ Improved | 1% | 0% |
Retrieve current FPF source only when pattern choice is material to the diagnosis. Mechanical reproduction, logs, and direct implementation probes do not need a ritual query. Inspect a known SourceID/UnitID directly; otherwise use mode="concern" and treat the returned candidate_set as incomplete navigation, not a selected pattern. Before relying on one candidate, inspect its exact identifier and direct pattern body. Keep several candidates live or abstain when the returned basis is insufficient. Never run a query after the diagnosis merely to manufacture source support for an already-chosen story.
Keep symptom, hypothesis, probe, observation, and verdict distinct. Include a rival that challenges the initial framing. Prefer safe parallel probes; label design-time inference separately from runtime evidence. Keep losing hypotheses with return conditions. Persist only on explicit request or when a named receiving use needs replay.
Other measured skills in the registry, with their headline benchmark lift.