gfix

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: Amend a git commit further back in the history. Use the gfix shell command to fold staged changes into a commit that is not the…
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 “How gfix works”, “When to use gfix”, “Steps”, 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 gfix 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 “How gfix works / When to use gfix / Steps” 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 / write / 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.

gfix — Amend a Past Commit

Use the gfix shell command to fold staged changes into a commit that is not the most recent. This is the preferred way to amend historical commits in this repo.

How gfix works

Source: ~/code/dotfiles/plugins/git.zsh (the gfix function)

gfix [-m <message>] <commit-sha> does the following:

Guards against running during an in-progress git operation (rebase, merge, cherry-pick, etc.)
Stashes any unstaged changes (preserving the index)
Creates a fixup commit from whatever is currently staged:
- With no -m: git commit --fixup <commit-sha> (content-only fixup)
- With -m <message>: creates a manual amend! commit with subject amend! <original-subject> and body <message>, which autosquash then folds into the target (replacing its message, and including any staged changes; --allow-empty is used if nothing is staged)
Runs GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash <commit-sha>^ to automatically squash the fixup into the target commit
Restores any stashed unstaged changes

When to use gfix

Use gfix when you need to amend a commit that is not the HEAD commit. For example:

A review comment asks for a change to code introduced 3 commits ago
You notice a typo or bug in an earlier commit while working on something else
You want to keep a clean, logical commit history where each commit is self-contained

If you only need to amend the most recent commit, use git commit --amend instead.

Steps

Determine the safe range — The target commit must be within the current branch's own commits, not on or before the base branch. Use detect_base_branch to find the base branch. As a last resort, ask the user.

The target commit must appear in git log --oneline <base-branch>..HEAD. If it does not, stop and tell the user — rewriting shared history would cause problems.
Identify the target commit — Use $ARGUMENTS to understand what the user wants fixed. List the safe commits with git log --oneline <base-branch>..HEAD and examine their diffs to find the commit that introduced the code the user wants changed.
Make and stage the changes — Edit the files, then git add only the files that belong to the target commit.
Run gfix — Pass the target commit SHA. Add -m <message> to also rewrite the target commit's message:
```
gfix <commit-sha>
gfix -m "new commit message" <commit-sha>
```
Handle rebase conflicts — If the rebase hits conflicts:
- Read the conflicting files and resolve them
- git add the resolved files
- git rebase --continue
- Repeat until the rebase finishes
Verify — Run git log --oneline -10 to confirm the history looks correct. If relevant tests exist, run them.

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
Write / modify
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 gfix.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# gfix — Amend a Past Commit

Use the `gfix` shell command to fold staged changes into a commit that is not the most recent. This is the preferred way to amend historical commits in this repo.

## How gfix works

Source: `~/code/dotfiles/plugins/git.zsh` (the `gfix` function)

`gfix [-m <message>] <commit-sha>` does the following:

1. Guards against running during an in-progress git operation (rebase, merge, cherry-pick, etc.)
2. Stashes any unstaged changes (preserving the index)
3. Creates a fixup commit from whatever is currently staged:
   - With no `-m`: `git commit --fixup <commit-sha>` (content-only fixup)
   - With `-m <message>`: creates a manual `amend!` commit with subject `amend! <original-subject>` and body `<message>`, which autosquash then folds into the target (replacing its message, and including any staged changes; `--allow-empty` is used if nothing is staged)
4. Runs `GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash <commit-sha>^` to automatically squash the fixup into the target commit
5. Restores any stashed unstaged changes

## When to use gfix

Use gfix when you need to amend a commit that is **not** the HEAD commit. For example:

- A review comment asks for a change to code introduced 3 commits ago
- You notice a typo or bug in an earlier commit while working on something else
- You want to keep a clean, logical commit history where each commit is self-contained

If you only need to amend the most recent commit, use `git commit --amend` instead.

## Steps

1. **Determine the safe range** — The target commit must be within the current branch's own commits, not on or before the base branch. Use `detect_base_branch` to find the base branch. As a last resort, ask the user.

…

Evidence boundary and execution chain

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

sections -> How gfix works → When to use gfix → Steps
terms    -> not · Determine the safe range · must · stop and tell the user · Identify the target commit · Make and stage the changes · Run gfix · Handle rebase conflicts
files/cmd -> gfix · ~/code/dotfiles/plugins/git.zsh · gfix [-m <message>] <commit-sha> · git commit --fixup <commit-sha> · -m <message> · amend! · amend! <original-subject> · <message>
body sha256 -> 61a1eecc2a41