Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Root-cause a bug with a hypothesis-driven loop instead of shotgun edits. Use when a bug isn't obvious after the first look, or when asked to "find out why" something fails.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-08 | ✗→✓ | ▲ Improved | 0% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 5% | 0% |
| case-14 | ✗→✓ | ▲ Improved | -27% | 0% |
| case-15 | ✗→✓ | ▲ Improved | -11% | 0% |
| case-16 | ✗→✓ | ▲ Improved | 20% | 0% |
Never fix what you can't reproduce; never explain what you haven't observed. The loop is: reproduce → observe → hypothesize → test the hypothesis → narrow. One variable at a time.
failure deterministically. If it's flaky, make the loop tight (while ./repro; do :; done) and treat flakiness itself as a clue (timing, ordering, shared state).
your own code, and the line right before things went wrong. Resist pattern-matching to a familiar failure — verify this one.
a restart") and pick the cheapest observation that could kill it: a log line, an assertion, a debugger breakpoint, one curl.
git bisect run ./reprodescend into the guilty one only
cause produces exactly this behavior. If the explanation is fuzzy, you've found a bug, maybe not the bug.
fails without the fix. Then look for siblings — the same mistake usually exists elsewhere (grep for the pattern you just fixed).
and outputs at the boundary.
Other measured skills in the registry, with their headline benchmark lift.