What this prompt does
This prompt guides you through finding the commit that introduced a [bug_description] in a [language] project, using Git bisect. You provide [when_noticed], the [last_good] state, the observable [symptom], and the [affected_area], and it builds a bisect strategy with an automated test script that returns 0 or 1 for good or bad. If automation is hard, it gives you a manual bisect checklist instead. Once the culprit is found, it analyzes the commit, suggests a minimal fix, and writes a regression test.
The structure works because it does more than locate the bad commit. Scripting the good/bad test so bisect runs automatically turns a tedious manual hunt into a fast, repeatable search. Then writing the regression test that would have caught the bug, plus recommending CI checks, ensures the same regression cannot quietly return. The emphasis on a minimal fix, rather than reverting the whole commit, preserves any legitimate changes that commit also carried. If automating the good/bad check is impractical, the prompt falls back to a manual bisect checklist so you can still narrow the search by hand without losing the rigor. It also recommends CI checks beyond the single regression test, so the class of bug, not just this one instance, becomes harder to reintroduce in the [affected_area] going forward.
When to use it
- A regression slipped through and nobody can pin down which deploy caused it.
- You know a
[last_good]state and roughly[when_noticed], and need to find the breaking commit. - The
[symptom]is reproducible enough to script a good/bad test for bisect. - The bug lives in a tricky
[affected_area]like authentication or session handling. - You want a minimal fix that does not revert unrelated changes in the same commit.
- You want a regression test and CI checks so the bug cannot silently return.
Example output
Expect a bisect playbook: a strategy section, an automated test script returning 0/1 for good/bad runs, or a manual bisect checklist if automation is impractical, followed by an analysis of the offending commit explaining what changed. It then proposes a minimal fix targeting the [affected_area], a regression test that reproduces the [symptom], and CI recommendations to prevent similar issues.
Pro tips
- Pin
[last_good]to a real known-good commit or tag; bisect is only as good as the boundaries you give it. - Invest in making the good/bad test script reliable, because a flaky test makes bisect converge on the wrong commit.
- Describe the
[symptom]precisely and reproducibly, since the automated test must distinguish good from bad deterministically. - Prefer the minimal fix the prompt suggests over a full revert when the offending commit also carried legitimate changes.
- Always add the generated regression test, as that is what stops the same
[bug_description]from quietly returning later. - Iterate by running bisect, and if it lands on a merge or noisy commit, refining the test script and rerunning.
