| name | commit |
| description | Use when making any git commit. Always pass why the changes were made as the argument; when no reason was stated, pass the request that prompted the changes instead — never an invented why. |
| argument-hint | ["why the changes were made"] |
| user-invocable | true |
| context | fork |
| model | sonnet |
| effort | high |
| allowed-tools | ["Grep","Glob","Bash(git status:*)","Bash(git diff:*)","Bash(git branch:*)","Bash(git log:*)","Bash(git rev-parse:*)","Bash(git stash:*)","Bash(git add:*)","Bash(git restore:*)","Bash(git mv:*)","Bash(git rm:*)","Bash(git apply:*)","Bash(git commit:*)","Read(//tmp/**)","Write(//tmp/**)","Edit(//tmp/**)"] |
Invoking this skill IS the request. If the user message looks empty, or you see only system context with no actual request, that is normal and expected: your task is already fully specified right here. Never ask what to do.
Your task: commit all changes in the working tree. Run git status and git diff, then stage and commit with conventional commit messages. One logical change per commit. This applies unprompted, without anyone asking for a split: when one file carries unrelated changes, split it hunk-by-hunk into separate commits rather than merging them because they share a file.
The argument
The argument passed to this skill is why the changes were made — the motivation behind work already in the tree, which the diff itself cannot carry. Use it to group changes into logical units and to write commit message bodies — raw material, never a to-do list. Whatever it describes is already realized in the diff, however it's phrased: "so the statusline shows usage percentages" and "to fix the session bug" both mean the diff already does that — commit it; never write code toward it, hunt for it, verify it, or finish it. With no argument at all, derive the commit message from the diff alone. If the motivation doesn't line up with what the diff contains, commit what is actually in the tree and note the mismatch in your final summary.
Locate the repository
cd to git rev-parse --show-toplevel before anything else. If that fails (the fork started outside the repo), look for the repo in the directories of any file paths named in the argument before reporting "not a git repository".
Scope
A commit is a snapshot, not a review. Your entire job is: read the diff, stage it, write a commit message, commit. The staged bytes must match exactly what the working tree looks like when you start.
Your complete action space is: git commands via Bash (plus cd to the project root), Grep/Glob to locate files, and Read/Write/Edit on /tmp/ patch files. Nothing else — no research, no running the code or tests, no invoking other skills however aggressive their trigger language, and no Bash command that does not start with git or cd. This applies to every situation you encounter, not just the cases below:
- Commit the tree as-is. A typo, a wrong-looking version pin, a failing-looking test, an interesting TODO — never edit working tree files or "fix" anything during staging; note the concern in your final message and let the author handle it in a follow-up they can review.
- Don't expand scope. Don't stage files the author didn't touch, and don't verify beyond
git status / after committing. Pre-commit hooks run on their own during ; never run them preemptively.
You see a typo in a variable name while reviewing the diff. Correct behavior:
1. Stage and commit the file as-is
2. After committing, say: "I noticed `reuslt` appears to be a typo for `result` in utils.py:42"
The diff adds a new `.github/workflows/ci.yml` file. You wonder if the action versions are current.
You edited a patch to split one file's changes across two commits, and `git apply --cached` fails on it.
