bisect

Engineering Community

Repo stars 2,380
License MIT
Author repo dotfiles

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Git bisect to find the first bad commit by running a test command. Use git bisect to binary-search through commit history and fi…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Step 1: Ensure clean working tree”, “Step 2: Determine the test command”, “Step 3: Verify the current commit is bad”, “Step 4: Find a good commit”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name bisect directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Step 1: Ensure clean working tree / Step 2: Determine the test command / Step 3: Verify the current commit is bad” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / shell-exec; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

bisect — Find the First Bad Commit

Use git bisect to binary-search through commit history and find the first commit that introduced a failure.

Step 1: Ensure clean working tree

Check that there are no staged or unstaged changes. If there are, stop and tell the user they need a clean working tree before bisecting, since git bisect checks out older commits.

git status --porcelain

If the output is non-empty, stop and ask the user to commit or stash their changes first.

Step 2: Determine the test command

Use $ARGUMENTS to understand what the user wants to test. This should describe a command or check that fails on the current commit. Determine the exact shell command to run.

Step 3: Verify the current commit is bad

Run the test command on the current commit (HEAD). If it passes (exits 0), stop and tell the user — the current commit doesn't exhibit the failure, so there's nothing to bisect.

Step 4: Find a good commit

Start searching backwards from HEAD in steps of 10 commits to find a commit where the test passes.

git stash --include-untracked -q 2>/dev/null; true
git checkout HEAD~10 --quiet

Run the test command. If it still fails, go back another 10 commits (HEAD~10 from the current position). Repeat until either:

A passing commit is found, or
You've gone back 100+ commits without finding a passing one — stop and ask the user for guidance (maybe a known-good commit SHA).

Once a good commit is found, note its SHA.

Step 5: Run git bisect

Return to the original branch first, then start bisecting:

git checkout - --quiet
git bisect start
git bisect bad
git bisect good <good-commit-sha>

Git will check out a middle commit. Run the test command on it:

If the test fails → git bisect bad
If the test passes → git bisect good

Repeat until git reports the first bad commit.

Step 6: Record the result and clean up

Save the first bad commit SHA and message. Then reset:

git bisect reset

Step 7: Report

Tell the user the first bad commit, including:

The commit SHA
The commit message
The commit author and date
A brief git show --stat of the commit so they can see which files changed

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Engineering
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 94 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @ryanb · MIT
Fluxly token estimate: Lean
Fluxly setup estimate: Guided setup
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Shell exec
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview bisect.preview

# Step 6: Record the result and clean up

git bisect reset

SKILL.md SKILL.md

# bisect — Find the First Bad Commit

Use `git bisect` to binary-search through commit history and find the first commit that introduced a failure.

## Step 1: Ensure clean working tree

Check that there are no staged or unstaged changes. If there are, **stop and tell the user** they need a clean working tree before bisecting, since git bisect checks out older commits.

```bash
git status --porcelain
```

If the output is non-empty, stop and ask the user to commit or stash their changes first.

## Step 2: Determine the test command

Use `$ARGUMENTS` to understand what the user wants to test. This should describe a command or check that fails on the current commit. Determine the exact shell command to run.

## Step 3: Verify the current commit is bad

Run the test command on the current commit (HEAD). If it **passes** (exits 0), stop and tell the user — the current commit doesn't exhibit the failure, so there's nothing to bisect.

## Step 4: Find a good commit

Start searching backwards from HEAD in steps of 10 commits to find a commit where the test passes.

```bash
git stash --include-untracked -q 2>/dev/null; true
git checkout HEAD~10 --quiet
```

Run the test command. If it still fails, go back another 10 commits (`HEAD~10` from the current position). Repeat until either:
- A passing commit is found, or
- You've gone back 100+ commits without finding a passing one — stop and ask the user for guidance (maybe a known-good commit SHA).

Once a good commit is found, note its SHA.

## Step 5: Run git bisect

Return to the original branch first, then start bisecting:

```bash
git checkout - --quiet
git bisect start
git bisect bad
git bisect good <good-commit-sha>
```

Git will check out a middle commit. Run the test command on it:
- If the test **fails** → `git bisect bad`

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Step 1: Ensure clean working tree → Step 2: Determine the test command → Step 3: Verify the current commit is bad → Step 4: Find a good commit → Step 5: Run git bisect → Step 6: Record the result and clean up
terms    -> stop and tell the user · passes · fails · Use git bisect to binary-search through commit history and find the first commit that introduced a failure. · Check that there are no staged or unstaged changes. · If the output is non-empty, stop and ask the user to commit or stash their changes first. · Use $ARGUMENTS to understand what the user wants to test. · Run the test command on the current commit (HEAD).
files/cmd -> git bisect · $ARGUMENTS · HEAD~10 · git bisect bad · git bisect good · git show --stat
body sha256 -> e3439ad7e889