Binary search debugging to isolate bug location in a large codebase. Use when you know a bug exists but don't know where — especially in large codebases, long execution paths, or complex data pipelines. Trigger for: "I don't know which part is broken", "the bug is somewhere in this 2000-line function", "it works up to some point then fails", or any debugging situation where the search space is too large to inspect manually.
Named after the classic problem: "There's one wolf in Alaska; how do you find it? Build a fence down the middle, wait for it to howl, determine which side it's on, and repeat."
The same logic applies to bugs: repeatedly divide the search space in half until the bug is isolated to a specific function, loop, or line.
Before dividing, define the two endpoints:
Ask the user:
of the current search space
Insert a diagnostic checkpoint at the midpoint:
Test and observe:
Narrow and repeat — update boundaries, pick new midpoint, repeat
Continue until the bug is isolated to a single function or a handful of lines.
Before starting the binary search, use available information to narrow the initial search space:
git log --oneline -20 -- <file>)Once narrowed to a small code section:
# Wolf Fence Debug Analysis
**Target bug:** [description]
**Initial search space:** [entry point] → [exit point]
## Search Path
### Iteration 1
- **Search space:** [range]
- **Checkpoint:** [location — file:function:line]
- **State check:** [what was verified]
- **Result:** State [correct/incorrect] → Bug in [first/second] half
- **Evidence:** [what was observed]
### Iteration 2
[same format]
[continue for all iterations]
## Bug Location
**File:** [path]
**Function:** [name]
**Lines:** [range]
**Description:** [what the bug is doing]
## Minimal Reproduction
[Smallest code that triggers the bug]
## Root Cause
[Why this code fails]
## Recommended Fix
[Suggested solution]
## Verification
- [ ] Bug reproducible at isolated location
- [ ] Fix resolves the failure
- [ ] No regressions at earlier checkpoints