git-bisect-assistant
Automatically performs git bisect to identify the first bad commit that introduced a bug or failure. Use when debugging regressions, tracking down when a test started failing, or identifying which commit broke functionality. Handles flaky tests with retry logic and provides comprehensive reports with bisect logs and confidence levels.
git clone --depth 1 https://github.com/ArabelaTso/Skills-4-SE /tmp/git-bisect-assistant && cp -r /tmp/git-bisect-assistant/skills/git-bisect-assistant ~/.claude/skills/git-bisect-assistantSKILL.md
# Git Bisect Assistant Automates the git bisect process to efficiently identify the first bad commit responsible for a bug or test failure. ## Quick Start Basic usage pattern: ```bash python scripts/git_bisect_runner.py \ --good <known-good-commit> \ --bad <known-bad-commit> \ --test "<test-command>" ``` Example: ```bash python scripts/git_bisect_runner.py \ --good v1.0.0 \ --bad HEAD \ --test "pytest tests/test_feature.py::test_specific_case" ``` ## Workflow 1. **Gather Information** - Identify the known good revision (commit, tag, or branch) - Identify the known bad revision (defaults to HEAD) - Determine the test command that fails on bad commits and passes on good commits 2. **Run Bisect** - Execute the `git_bisect_runner.py` script with appropriate parameters - The script will automatically test commits and narrow down the culprit 3. **Review Results** - Examine the identified bad commit - Review the bisect log showing all tested commits - Check confidence level and assumptions ## Parameters ### Required - `--good`: Known good revision (commit hash, tag, or branch name) - `--test`: Shell command to test each commit. Exit code 0 = good, non-zero = bad ### Optional - `--bad`: Known bad revision (default: `HEAD`) - `--repo`: Repository path (default: current directory) - `--retries`: Number of test runs per commit for flaky tests (default: 1) - `--timeout`: Test execution timeout in seconds (default: no timeout) ## Handling Flaky Tests For non-deterministic tests, use `--retries` to run the test multiple times per commit: ```bash python scripts/git_bisect_runner.py \ --good abc123 \ --bad HEAD \ --test "npm test" \ --retries 3 ``` The script uses majority voting: if a test passes 2 out of 3 times, the commit is marked as good. ## Test Command Guidelines The test command should: - Exit with code 0 for good commits (test passes) - Exit with non-zero code for bad commits (test fails) - Be deterministic or use `--retries` for flaky tests - Complete within reasonable time or use `--timeout` Examples: ```bash # Python test --test "pytest tests/test_auth.py -v" # Shell script --test "./scripts/verify_build.sh" # Compilation check --test "make && ./bin/app --version" # Multiple commands --test "npm install && npm test" ``` ## Output Report The script generates a comprehensive report including: - **First Bad Commit**: Hash and commit message of the culprit - **Confidence Level**: Assessment based on test stability and retry logic - **Assumptions**: Any assumptions made during bisect (retries, timeouts) - **Tested Commits**: Complete list of all commits tested with results - **Bisect Log**: Detailed log of the bisect process ## Common Scenarios ### Scenario 1: Test Started Failing User: "The integration tests started failing sometime in the last 20 commits" ```bash python scripts/git_bisect_runner.py \ --good HEAD~20 \ --bad HEAD \ --test "pytest tests/integration/" ``` ### Scenario 2: Feature Broke After Release User: "Feature X worked in v2.1.0 but is broken now" ```bash python scripts/git_bisect_runner.py \ --good v2.1.0 \ --bad HEAD \ --test "python -c 'import app; assert app.feature_x() == expected'" ``` ### Scenario 3: Flaky Test Investigation User: "A test fails intermittently, need to find when it started" ```bash python scripts/git_bisect_runner.py \ --good main \ --bad feature-branch \ --test "pytest tests/test_flaky.py" \ --retries 5 \ --timeout 30 ``` ## Tips - **Ensure clean state**: Commit or stash changes before running bisect - **Fast tests**: Use focused tests rather than full test suites for faster bisect - **Build requirements**: Include build steps in test command if needed - **Dependencies**: Ensure test command handles dependency installation if needed across commits - **Timeout wisely**: Set timeout slightly longer than expected test duration - **Retry count**: Use 3-5 retries for flaky tests to get reliable results ## Troubleshooting **Bisect fails to start**: Verify good and bad revisions exist and are valid git references **Test command fails unexpectedly**: Test the command manually on a known good/bad commit first **Inconsistent results**: Increase `--retries` or check for environmental factors affecting tests **Timeout too short**: Increase `--timeout` or optimize test command
Applies abstract interpretation using different abstract domains (intervals, octagons, polyhedra, sign, congruence) to statically analyze program variables and infer invariants, value ranges, and relationships. Use when analyzing program properties, inferring loop invariants, detecting potential errors, or understanding variable relationships through static analysis.
Uses abstract interpretation to automatically infer loop invariants, function preconditions, and postconditions for formal verification. Generates invariants that capture program behavior and support correctness proofs in Dafny, Isabelle, Coq, and other verification systems. Use when adding formal specifications to code, generating verification conditions, inferring contracts for functions, or discovering loop invariants for proofs.
Performs abstract interpretation over source code to infer possible program states, variable ranges, and data properties without executing the program. Reports potential runtime errors including out-of-bounds accesses, null dereferences, type inconsistencies, division by zero, and integer overflows. Use when analyzing code for potential runtime errors, performing static analysis, checking safety properties, or verifying program behavior without execution.
Performs abstract interpretation to produce summarized execution traces and high-level program behavior representations. Highlights key control flow paths, variable relationships, loop invariants, function summaries, and potential runtime states using abstract domains (intervals, signs, nullness, etc.). Use when analyzing program behavior, understanding execution paths, computing loop invariants, tracking variable ranges, detecting potential runtime errors, or generating program summaries without concrete execution.
Create ACSL (ANSI/ISO C Specification Language) formal annotations for C/C++ programs. Use this skill when working with formal verification, adding function contracts (requires/ensures), loop invariants, assertions, memory safety annotations, or any ACSL specifications. Supports Frama-C verification and generates comprehensive formal specifications for C/C++ code.
CLI-based browser automation with persistent page state using ref-based element interaction. Use when users ask to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
Detects and analyzes ambiguous language in software requirements and user stories. Use when reviewing requirements documents, user stories, specifications, or any software requirement text to identify vague quantifiers, unclear scope, undefined terms, missing edge cases, subjective language, and incomplete specifications. Provides detailed analysis with clarifying questions and suggested improvements.
Design and review APIs with suggestions for endpoints, parameters, return types, and best practices. Use when designing new APIs from requirements, reviewing existing API designs, generating API documentation, or getting implementation guidance. Supports REST APIs with focus on endpoint structure, request/response schemas, authentication, pagination, filtering, versioning, and OpenAPI specifications. Triggers when users ask to design, review, document, or improve APIs.