Skip to content

SKILL.md

Latest commit

 

History

History
161 lines (107 loc) · 5.8 KB

SKILL.md

File metadata and controls

161 lines (107 loc) · 5.8 KB
name git-commit-renamer
description Safely rename Git commit messages, including the latest commit, older local commits, and already-pushed commits that require history rewrites. Use this skill whenever the user wants to rename, reword, edit, fix, or change a Git commit message, whether they say "last commit," "older commit," "unpushed commit," "pushed commit," "commit on remote," or ask how to do it safely without breaking history.

Git Commit Renamer

Use this skill when the task is to rename one or more Git commit messages. The main goal is to choose the safest workflow for the commit's state:

  • Unpushed latest commit
  • Unpushed older commit
  • Pushed commit on a remote branch

The critical distinction is whether the commit has been pushed. Renaming an unpushed commit is usually straightforward. Renaming a pushed commit rewrites history and can disrupt collaborators unless handled carefully.

Core rules

  1. Determine whether the target commit has been pushed before suggesting or running rewrite commands.
  2. Prefer the smallest rewrite that solves the task.
  3. Never rewrite shared remote history casually. If the commit is already pushed, make the user-facing risk explicit.
  4. When rewriting a pushed branch, prefer git push --force-with-lease over --force.
  5. Do not use destructive Git commands like git reset --hard unless the user explicitly asks.
  6. Verify the resulting history with a log command after the rename.

First step

Inspect the branch and identify:

  • Which commit needs renaming
  • Whether it is the latest commit or an older one
  • Whether it exists on the upstream branch
  • Whether the working tree is clean enough for a rebase or amend

Useful inspection commands:

git status --short
git branch --show-current
git log --oneline --decorate -n 10
git rev-parse --abbrev-ref --symbolic-full-name @{u}
git log --oneline @{u}..HEAD

Interpretation:

  • If the commit is only in @{u}..HEAD, it has not been pushed to the upstream branch.
  • If the commit is already on the remote branch, renaming it will require history rewriting and a force-push.

If no upstream branch exists, say so clearly and treat the branch as not yet pushed unless other evidence says otherwise.

Workflow selection

Case 1: Rename the latest commit and it has not been pushed

Use:

git commit --amend -m "New commit message"

Then verify:

git log --oneline -n 3

This is the preferred path for the common "rename my last commit" request.

Case 2: Rename an older commit that has not been pushed

Use interactive rebase with reword:

git rebase -i HEAD~N

Where N includes the target commit in the rebase range. Change the target commit from pick to reword, save, then provide the new message when Git prompts for it.

After the rebase:

git log --oneline --decorate -n 10

If conflicts appear, resolve them, continue the rebase, and confirm the final history.

Case 3: Rename the latest commit and it has already been pushed

Use:

git commit --amend -m "New commit message"
git push --force-with-lease

Only do this when the user wants the remote history rewritten and understands the branch impact. Make it explicit that collaborators may need to re-sync their local branch.

Case 4: Rename an older commit that has already been pushed

Use interactive rebase plus a safe force-push:

git rebase -i HEAD~N
git push --force-with-lease

This is the highest-risk case because it rewrites published history for the target commit and every descendant commit in the rewritten range.

How to communicate risk

When the commit is already pushed, clearly say:

  • The branch history will be rewritten.
  • Anyone else using that branch may need to rebase or reset their local copy.
  • --force-with-lease is safer than --force because it refuses to overwrite unexpected remote updates.

Do not be vague about this. The user should understand that a pushed commit rename is not just a local metadata edit.

Recommended execution pattern

  1. Inspect the branch and upstream state.
  2. Tell the user which case applies.
  3. Run the minimal rename workflow.
  4. If a pushed branch was rewritten, push with --force-with-lease.
  5. Show the relevant final log output in a concise summary.

Response template

When carrying out the task, structure the result like this:

Target commit: <latest commit or specific hash>
State: <unpushed latest | unpushed older | pushed latest | pushed older>
Action taken: <amend | interactive rebase | amend + force-with-lease | rebase + force-with-lease>
Verification: <short log summary>
Risk note: <only include when pushed history was rewritten>

Guardrails

  • If the user only asks for instructions, explain the right command sequence without running it.
  • If the repo is in the middle of a rebase, merge, or cherry-pick, stabilize that state before starting another history rewrite.
  • If there are uncommitted changes that could interfere with the rewrite, call that out and decide whether to proceed carefully or ask the user.
  • If the branch is shared and the user does not clearly want a rewrite, recommend making a follow-up commit instead of rewriting published history.

Examples

Example 1: User: "Rename my last commit to fix the wording."

Apply git commit --amend -m ... if it is not pushed yet. If it was pushed, explain that the remote branch must be force-pushed with --force-with-lease.

Example 2: User: "Change the message for the commit three back."

Use git rebase -i HEAD~3 or a larger range that includes the target commit, mark it as reword, then verify the updated history.

Example 3: User: "Rename the commit that is already on origin/main."

Treat this as a pushed-history rewrite. Make the risk explicit and use rebase or amend as appropriate, followed by git push --force-with-lease.