bisect-regression

Run git bisect to find the first bad commit using a named test predicate.

3|1|Updated May 28, 2026
One-click install
npx skills add https://github.com/VMAFx/vmafx --skill bisect-regression
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: bisect-regression
Source: https://github.com/VMAFx/vmafx/tree/main/.claude/skills/bisect-regression
Command: npx skills add https://github.com/VMAFx/vmafx --skill bisect-regression

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you pinpoint the first commit that introduced a regression without manually testing every change.

Core Features & Use Cases

  • Runs git bisect against a known good commit and a known bad commit.
  • Supports multiple regression checks, including test failures, score deltas, performance drops, and golden-test outcomes.
  • Useful when a change breaks builds, tests, quality scores, or throughput and you need the exact commit responsible.

Quick Start

Ask the assistant to bisect a regression by providing the good commit, bad commit, and the predicate you want evaluated.

Frequently Asked Questions about bisect-regression

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

FAQPage Schema
How do I find the first bad commit in a git regression range?

Git bisect identifies the first bad commit by running a binary search between known good and bad commits, applying a test predicate to each state to determine if the regression is present.

Can I use a unit test or performance threshold to check for regressions during git bisect?

Yes, you can use a unit test, golden check, score delta, or performance threshold as the named predicate to evaluate whether a specific checked-out commit is good or bad during the automated bisect run.

How does git bisect handle uncommitted changes or a dirty working tree?

Git bisect handles a dirty working tree by enforcing clean-tree validation, automatically stashing uncommitted changes before checking out the next commit, and restoring them safely after the regression search completes.

What happens if a build fails and the commit needs to be skipped during a bisect run?

When a build fails during a bisect run, the workflow applies safe skip handling to exclude the untestable commit, allowing the binary search to continue finding the actual regression without manual intervention.

Do I need to manually run git bisect commands to find a regression?

You do not need to manually run git bisect commands; you provide the good commit, bad commit, and evaluation predicate, and the automated reproducible workflow executes the binary search to pinpoint the regression.