Use when needing to reorder, split, drop, or amend git commits that are not the top commit, without interactive editor access. Covers programmatic rebase via GIT_SEQUENCE_EDITOR, commit splitting with automated hunk selection, and metadata changes (author, message, dates) on any commit in a range.
npx skills add https://github.com/facebook/hermes --skill non-interactive-git-rebase
git rebase -i normally opens an editor for the todo list. By setting GIT_SEQUENCE_EDITOR to a command that replaces the todo file with a pre-prepared one, you can perform any interactive rebase operation — reorder, drop, squash, edit, amend — entirely from scripts.
Before any rebase, create a backup branch:
git branch backup-before-rebase HEAD
After the rebase succeeds and verification passes, do NOT delete the backup branch automatically. Always ask the user before deleting it, unless the user explicitly requested automatic cleanup. The backup is cheap to keep and the user may discover problems later.
The editor receives the todo file path as $1. Any command that overwrites that file works:
# Replace the todo with our prepared version
GIT_SEQUENCE_EDITOR="cp /tmp/prepared-todo" git rebase -i <base>
Git generates the default todo (all pick lines), then invokes cp /tmp/prepared-todo <todo-file>, which replaces it with your version. Git then executes the rewritten todo.
Extract the default todo without actually rebasing — copy it out, then fail the editor so git aborts:
GIT_SEQUENCE_EDITOR='cp $1 /tmp/default-todo && false' git rebase -i <base>
The false exits non-zero, so git aborts the rebase. You have the todo file, no rebase happened.
Or build it directly from git log:
git rev-list --reverse <base>..HEAD | while read hash; do
echo "pick $hash $(git log --oneline -1 $hash | cut -d' ' -f2-)"
done > /tmp/prepared-todo
Then edit the file: reorder lines, change pick to drop/squash/edit/etc.
The --exec <cmd> flag inserts an exec <cmd> line after every pick in the todo. Combined with GIT_SEQUENCE_EDITOR=: (a no-op that succeeds, leaving the default todo unchanged), this runs a command after each commit is replayed — no editor needed.
Change author email on all commits in a range:
GIT_SEQUENCE_EDITOR=: git rebase -i <base> --exec \
'if [ "$(git log -1 --format=%ae)" != "[email protected]" ]; then git commit --amend --no-edit --author="Name <[email protected]>"; fi'
Change commit message pattern:
GIT_SEQUENCE_EDITOR=: git rebase -i <base> --exec \
'git commit --amend -m "$(git log -1 --format=%B | sed s/old/new/)"'
Rearrange lines in the todo file. Example — move commit abc123 to the front:
# Build todo with abc123 first, then everything else in original order
{
echo "pick abc123 The commit to move first"
git rev-list --reverse <base>..HEAD | while read hash; do
full=$(git rev-parse abc123)
[ "$hash" != "$full" ] && echo "pick $hash $(git log --oneline -1 $hash | cut -d' ' -f2-)"
done
} > /tmp/prepared-todo
GIT_SEQUENCE_EDITOR="cp /tmp/prepared-todo" git rebase -i <base>
Remove lines from the todo, or change pick to drop.
NEVER use reword in the todo. The reword command opens an interactive editor for the new message, which cannot be scripted via GIT_SEQUENCE_EDITOR. Instead, use edit and amend with -m:
# Step 1: Prepare todo with 'edit' on commits to reword
# Step 2: At each stop, amend the message non-interactively:
git commit --amend -m "New subject line
New body text."
# Step 3: Continue to the next stop
git rebase --continue
Change pick to squash or fixup. For squash, you also need GIT_SEQUENCE_EDITOR for the commit message editor that opens after squashing:
# Squash second commit into first, keep first message
# In the todo: pick aaa, fixup bbb
GIT_SEQUENCE_EDITOR="cp /tmp/prepared-todo" git rebase -i <base>
This requires edit in the todo. When rebase stops, you run commands to split, then continue.
# Step 1: Prepare todo with 'edit' on the target commit
sed 's/^pick TARGET_HASH/edit TARGET_HASH/' /tmp/default-todo > /tmp/prepared-todo
GIT_SEQUENCE_EDITOR="cp /tmp/prepared-todo" git rebase -i <base>
# Step 2: Rebase stops at the target commit. Split it:
git reset HEAD~1
# Step 3: Selectively stage and commit pieces.
# If the commit has N hunks in a file and you want hunk 3:
printf 'n\nn\ny\n' | git add -p path/to/file
git commit -m "First piece: just hunk 3"
# Stage the rest
git add .
git commit -m "Second piece: remaining changes"
# Step 4: Continue the rebase
git rebase --continue
Automating hunk selection with git add -p: Each y/n in the printf corresponds to a hunk in order. This works reliably when hunks are well-separated (different regions of the file). If hunks are adjacent, git may present them as one hunk, and you may need s (split) first:
# Split first hunk, then accept/reject sub-hunks
printf 's\ny\nn\ny\n' | git add -p path/to/file
Alternative — patch-based splitting (more reliable for complex cases):
git reset HEAD~1
git diff path/to/file > /tmp/full.patch
git checkout -- path/to/file
# Apply only the lines you want for commit 1
# (manually prepare /tmp/part1.patch from full.patch)
git apply /tmp/part1.patch
git add path/to/file
git commit -m "First piece"
git apply /tmp/full.patch # won't re-apply already-applied hunks
# Or: git checkout <original-hash> -- path/to/file
git add .
git commit -m "Second piece"
After any rebase, verify the tree content is identical to before (unless you intentionally dropped commits):
git diff backup-before-rebase HEAD --stat
# Empty output = content preserved correctly
| Mistake | Fix |
|---------|-----|
| Using reword in the todo | reword opens an interactive editor. Use edit + git commit --amend -m instead |
| Todo file has wrong hashes after prior rebase | Regenerate from git log — hashes change after every rebase |
| git add -p gets unexpected hunks | Hunks may merge if context overlaps. Use patch-based splitting instead |
| Deleting backup branch too early | Always ask the user before deleting. They may discover problems later |
| Operation | Command |
|-----------|---------|
| Extract todo | GIT_SEQUENCE_EDITOR='cp $1 /tmp/default-todo && false' git rebase -i <base> |
| Reorder/drop | GIT_SEQUENCE_EDITOR="cp /tmp/prepared-todo" git rebase -i <base> |
| Reword message | Same as above, use edit in todo, then git commit --amend -m "..." + --continue |
| Squash (keep msg) | Same as above, use fixup in todo |
| Squash (edit msg) | Same as above, use squash, then handle message editor |
| Split | Same as above, use edit, then manual split + --continue |
| Bulk amend | GIT_SEQUENCE_EDITOR=: git rebase -i <base> --exec '<cmd>' |
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
Take facebook/non-interactive-git-rebase from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.