What this prompt does
This prompt frames the model as a senior engineer debugging a production regression and asks for runnable commands and a real git bisect test script, not pseudocode. Four placeholders make it specific: [bug_description] (the regression you are hunting), [good_ref] (a known-good commit or tag), [bad_ref] (a known-bad reference), and [stack] (the language and test runner the script targets).
The structure works because bisect is only as good as its test script. By demanding the exact git bisect start sequence from your refs, a self-contained script that exits 0 when the bug is absent and non-zero when present with a skip code for un-buildable commits, handling for merge commits and flaky tests, commands to confirm the culprit, and a revert-vs-fix-forward rule, the prompt automates the search instead of leaving you guessing. The skip code (exit 125) keeps bisect from marking un-buildable commits as bad. Tailoring the script to [stack] matters because the build and test invocation differs by language and runner, and a script that does not actually exercise the regression will send bisect to a confidently wrong answer.
When to use it
- Something broke "sometime this week" and you need to find the exact offending commit fast.
- You want a scripted
git bisect runrather than manually testing each step. - You have a clear
[good_ref]and[bad_ref]to bound the search. - You need a test script for
[stack]that exits correctly per bug presence. - Your history has merge commits or flaky tests that could misdirect a naive bisect.
- You want a clear revert-vs-fix-forward decision rule once the culprit is found.
Example output
Expect numbered commands and a fenced test script. It starts with the git bisect start sequence using [good_ref] and [bad_ref], then a self-contained script for git bisect run written for [stack] that exits 0 when [bug_description] is absent, non-zero when present, and 125 to skip builds that fail to compile. It adds guidance on merge commits and flaky tests, commands to confirm the culprit with git show/git log, and a revert-vs-fix-forward decision rule with the safe revert command and how to reset bisect state.
Pro tips
- Make the script exit 125 on un-buildable commits so bisect skips them instead of wrongly marking them bad.
- Describe
[bug_description]as something the script can detect deterministically; a vague symptom makes the automated run unreliable. - Pick a
[good_ref]you are genuinely sure about — if the bug already exists there, bisect points at the wrong commit. - Address flaky tests up front (retry or pin) so flake does not send bisect down the wrong path.
- Once it lands, confirm with
git showbefore reverting, then reset bisect state so your working tree is clean. - Verify the script manually against
[good_ref]and[bad_ref]first — it should pass on one and fail on the other before you trust an automated run. - For an intermittent
[bug_description], run the check several times inside the script so a single lucky pass does not mark a bad commit as good.
