regression-bisect

Diagnose test regressions after refactoring using git bisect and semantic diff analysis.

Updated Mar 4, 2026
One-click install
npx skills add https://github.com/chisuhua/home --skill regression-bisect-chisuhua
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: regression-bisect
Source: https://github.com/chisuhua/home/tree/main/.config/opencode/skills/regression-bisect
Command: npx skills add https://github.com/chisuhua/home --skill regression-bisect-chisuhua

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a refactoring causes previously passing tests to fail, developers often guess at root causes or apply shotgun fixes. This Skill enforces a disciplined debugging methodology that locates the exact regression commit, compares old and new code semantics line by line, and cross-references all writers of shared state before any fix is attempted. ## Core Features & Use Cases - Regression Commit Localization: Uses git bisect and git diff to narrow a failure down to a single commit and read every changed file. - Semantic Change Analysis: Builds a comparison table of old vs. new read/write semantics for every modified method or accessor, exposing state migration risks. - Shared-State Cross-Referencing: Greps for all readers and writers of migrated state and draws modification timelines to reveal value drift, duplicate writes, and alias pollution. - Use Case: After moving a per-thread PC field into shared warp state, tests fail only in multi-threaded runs. Use this Skill to bisect the commit, trace every set_thread_pc call, and produce a minimal 1-3 line fix verified against the full test suite. ## Quick Start Ask the AI to use the regression-bisect skill to find which commit broke the tests after the recent refactor and identify the root cause before fixing it.

Frequently Asked Questions about regression-bisect

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find which commit broke my tests after a refactor?▼

Use git bisect with a known good commit and the current failing HEAD to binary-search the history. Once the bad commit is isolated, run git diff between good and bad to read every changed file before attempting any fix.

How to debug test regressions caused by moving fields to shared state?▼

Build a semantic comparison table listing what each accessor read and wrote before and after the change. Then grep for all writers of the shared state and draw a modification timeline to find where another code path overwrites the value.

Why do tests pass single-threaded but fail multi-threaded after refactoring?▼

This signal indicates a synchronization or shared-state problem. Check barriers, locks, and any state that was migrated from local fields to shared structures, since other threads or handlers may now modify values between reads.

What is shotgun debugging and why should I avoid it?▼

Shotgun debugging means changing multiple possibly-related locations at once without confirming the root cause. It hides the real bug, introduces new regressions, and makes verification impossible; always bisect and confirm the root cause first.

When should I not use git bisect for regression debugging?▼

Bisect is less useful when the failure is non-deterministic, depends on environment state, or when the good and bad commits have an enormous diff that cannot be built at intermediate points. In those cases, start with targeted diff reading and logging.