Git sequential
Skills that are authored by me.
npx -y skills add vladcheck/skills --skill git-sequentialAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when a pile of uncommitted changes (or one big commit/diff) should become a clean sequence of logical commits — incremental commits, splitting a big change, building a readable history as if the work were done step by step, staging hunks selectively before a PR.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.4 KB, as published. Nobody here has run it
git-sequential
Turn one undifferentiated blob of changes into an ordered sequence of small, coherent commits — as if the work had been done incrementally. Goal: a history that reads as a logical progression and (ideally) builds/passes at every step.
When to use
- You wrote everything at once but want a reviewable, story-like history.
- Splitting a big commit or diff before opening a PR.
- Want each commit to be independently understandable / bisectable.
Skip for trivial single-purpose changes — one commit is correct.
Workflow
- Survey.
git statusandgit diff(plusgit diff --staged). Know every changed and untracked file. - Plan the order. Sequence commits so each builds on the previous — dependencies/config first, then core/lib, then the feature that uses it, then tests, then docs. Write the list down before touching the index.
- Stage one step at a time:
- Whole file:
git add <file> - Selected hunks:
git add -p(y/nper hunk,sto split,eto hand-edit a hunk) - Surgical splits
-pcan't make:git add -e(edit the raw patch) - Untracked file you need to split:
git add -N <file>first (intent-to-add), thengit add -pcan offer its hunks.
- Whole file:
- Commit the step with a message scoped to just that step. Repeat 3–4 until
git statusis clean. - Verify:
git log --oneline. To prove every commit builds:git rebase -i --exec "<test cmd>" <base>— it stops on the first commit that fails.
Splitting an existing single commit
git reset HEAD~ # keep changes, drop the commit; working tree now dirty
# ...then run the Workflow above
Mid-history commit: git rebase -i <base>, mark it edit, then git reset HEAD^ and recommit in pieces. Reorder/squash later with the same interactive rebase.
Quick reference
| Need | Command |
|---|---|
| Stage hunks interactively | git add -p |
| Split a hunk further | s then e inside add -p |
| Stage part of an untracked file | git add -N <file> then git add -p |
| Hand-edit what gets staged | git add -e |
| Undo last commit, keep changes | git reset HEAD~ |
| Reorder / squash / edit history | git rebase -i <base> |
| Assert every commit builds | git rebase -i --exec "<cmd>" <base> |
Common mistakes
- Cross-dependent hunks in separate commits. If hunk B needs hunk A, put A's commit first or commit them together — otherwise the in-between commit is broken.
- Forgetting untracked files.
git add -pignores them untilgit add -N. Checkgit statusis clean at the end. - Faking a history that never built. If you care about bisectability, verify with
--exec. If you don't, say so and skip it. - Rebasing pushed/shared commits without coordinating — only rewrite history that's still local.