bisect-regressionlisted

# Bisect Regression ## Core Question Which commit introduced a regression, and what evidence supports that conclusion? ## When To Use Use this skill when: - the user has a known good and known bad commit or range - a reproducible test command can identify pass/fail - the user asks to bisect a regression - manual or automated bisect is appropriate ## When Not To Use Do not use this skill when: - debugging without a reproducible signal - fixing the regression after identification - running bisect on dirty user work - rewriting history or pushing results Route to: - dirty current work routes to `worktree-management`, `stash-shelve`, or `atomic-commits` - conflicts during checkout route to `undo-recover` or stop - root-cause fix routes to coding workflow outside this library ## Required Evidence Before action, inspect or establish: - known bad commit or current bad state - known good commit - test command and expected signal - clean or isolated worktree state - flakiness indicators - generated files or build artifacts that may change during test No-evidence rule: - Do not make strong claims without observed evidence. - State assumptions when proceeding under incomplete evidence. - Stop when missing evidence affects safety, correctness, user work, remote state, or irreversible action. ## Operating Contract You MAY: - inspect relevant repository state and project files. - generate a plan, report, or local artifact within the declared risk scope. - route to another