Binary search debugging
Skill Amey-Thakur/AI-SKILLS/skills/debugging/binary-search-debugging
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill binary-search-debuggingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Halve the search space repeatedly across code, data, time, and configuration until a single change isolates the failure. Use when the fault could live anywhere across a large surface and reading it all in order is too slow.
SKILL.md
2.5 KB, 542 tokens by cl100k_base, as published. Nobody here has run it
Binary search debugging
When a failure could start in any of a thousand lines, inputs, or flags, reading them in sequence is the slowest route there is. Bisection converts a thousand suspects into about ten questions: a probe at the midpoint either clears half the space or condemns it. The craft is choosing a clean midpoint in whichever dimension the bug is hiding.
Method
- Establish two anchor points before splitting. Find one state where the bug is present and one where it is absent. Without both ends you have nothing to bisect, only a hunch to chase.
- Bisect the code path. Drop a probe halfway down the call chain that asserts a known-good invariant. Holds there means the fault is downstream; broken means upstream. Move the probe into the surviving half and repeat.
- Bisect the data. Feed the first half of the failing input, then the second, keeping the half that still fails. A 10,000-row file that crashes narrows to the offending row in about 14 splits.
- Bisect configuration and feature flags. Toggle half the flags, plugins, or env overrides at once. When the outcome flips, the trigger sits in the set you just changed. Binary elimination beats flipping switches one at a time.
- Bisect uncommitted time by comment-out. For "it worked an hour ago" with no clean commit to blame, disable half the changed region and rerun. This finds the guilty block even inside a single unstaged edit.
- Change exactly one variable per step. Split data and code in the same run and a flipped result names neither cause. One cut, one rerun, one conclusion, written down before the next split.
- Stop at a one-line delta. Keep halving until the gap between pass and fail is a single line, row, or flag. That delta is either the bug or a finger pointing straight at it.
Signals
- Does each probe roughly halve the remaining suspects, not trim a handful?
- Are both anchor points still reproducible, or did one quietly drift?
- When a split flipped the outcome, was exactly one thing different?
Boundaries
Bisecting version history is mechanical enough to automate: hand that to git-bisect. When the space is already small or a stack trace names the line, read it directly instead of halving out of habit.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.