git-commit skill: step 3 can leave changes out of a merge commit, and git add --resolved has no fallback before Git 2.56 #6255

The git-commit skill (skills/git-commit/SKILL.md, as of 5406429) has two steps that go wrong for an agent in the middle of a merge. They also keep us on an older version of the skill, which still pre-approves all of Bash. Your current version narrows that to shell(git:*), which we would like to take.

1. Unstaging "other changes" during a merge drops them from the merge commit

Step 3 says:

Put one logical change in each commit. If the staged files contain more than one change, first unstage the files of the other changes.

git reset -q -- path/to/other-file1 path/to/other-file2

While a merge is in progress, the index holds the merge result. Files that merged cleanly from the other branch are already staged, and so are conflicts the agent has resolved and added. To an agent following step 3, those files look like a second, unrelated change, so it unstages them. git reset -q -- <path> puts the current branch's version back in the index, and git commit then records the merge commit with that version:

1. On main, run git merge topic, where topic changed feature.txt and both branches changed shared.txt.
2. Resolve shared.txt and stage it. feature.txt is already staged by the merge.
3. Following step 3, treat feature.txt as another change: git reset -q -- feature.txt, then git add -- shared.txt.
4. git commit.

The merge commit has both parents but main's old feature.txt. topic's change survives only as an uncommitted edit in the working tree. Git now considers topic merged, so merging it again does not bring the change back. The same happens to a resolved conflict that the agent unstages.

Cherry-picks and reverts have the same problem, through CHERRY_PICK_HEAD and REVERT_HEAD.

Suggested fix: before splitting, check whether an operation is in progress, for example with git rev-parse -q --verify MERGE_HEAD (and CHERRY_PICK_HEAD, REVERT_HEAD). If one is, never unstage. Commit the whole result as one commit, or stop and ask the user.

2. git add --resolved fails before Git 2.56

Step 3 also says to stage resolutions with git add --resolved. The compatibility field notes it needs Git 2.56 or later, but the step offers nothing else. Many agent hosts and CI images run older Git, for example 2.43 on Ubuntu 24.04 or 2.54 on current macOS. There the command fails with error: unknown option `resolved', and the agent is left without a way to stage the resolution.

Suggested fix: keep git add --resolved where it is available. Otherwise, list the unmerged paths with git diff --name-only --diff-filter=U, check them for leftover markers with git diff --check, and stage them with git add -- <paths>.

Why it matters beyond the merge itself

Plugin directories now flag skills that pre-approve unrestricted shell access. For example, Claude's plugin directory reports "Pre-approves broad shell access in allowed-tools". Your current allowed-tools: shell(git:*) fixes that, but consumers that pinned an older version because of the two problems above cannot take it until they are fixed.