| name | commit-snipe |
| user-invocable | true |
| description | Stage and commit only the current task's hunks when the worktree contains unrelated changes. |
Commit Snipe
Precision commits from a working tree with mixed changes. Stage only what belongs to the current task, leave the rest untouched.
When
git status shows changes that are NOT from the current work- Multiple logically independent tasks have touched the working tree
- The user says "commit" without specifying which files
Core technique
digraph snipe {
"User says commit" [shape=doublecircle];
"git status" [shape=box];
"Which files belong to\nTHIS conversation?" [shape=diamond];
"Stage only those files\n(explicit paths)" [shape=box];
"git diff --cached\nverification" [shape=box];
"Commit" [shape=doublecircle];
"User says commit" -> "git status";
"git status" -> "Which files belong to\nTHIS conversation?";
"Which files belong to\nTHIS conversation?" -> "Stage only those files\n(explicit paths)";
"Stage only those files\n(explicit paths)" -> "git diff --cached\nverification";
"git diff --cached\nverification" -> "Commit";
}
git status review all changes in the working tree- Conversation analysis which files did you create, edit, or generate in THIS session?
- Selective staging
git add with explicit file names
- Verification
git diff --cached --stat to check that only the right files are staged
- Commit follow existing conventions from the project- and user-CLAUDE.md
Rules
- Invocation IS commit intent.
/git-discipline:commit-snipe means "commit now". Do not ask for confirmation. The user has already given their intent by invoking the skill.
- When in doubt, do NOT stage. A file you cannot confidently trace back to the current work does not belong in the commit.
- Never
git add . or git add -A. Always explicit paths or hunks.
- Files are an implementation detail. The snipe might be two lines
inside a file with forty lines of changes. Use
git add -p
to stage only the hunks that belong to the current work. It is about
the functionality, not the file.
- No questions about which files. The conversation context IS the source of truth. You know which changes you touched.
- Count generated files. If you edited an SVG and generated PNGs from it, the PNGs belong with it.
- Multiple logical units = multiple commits. If the current work consists of independent steps, snipe per step.
- Snipe pre-existing changes too. When the user explicitly says "what is still there" or similar, commit all uncommitted changes. Group them into logical commits, even when they are not from the current session.
Anti-patterns
| Wrong | Correct |
|---|
| Stage everything because the user said "commit" | Only files from the current work |
| Ask "which files do you want to commit?" | Determine yourself from conversation context |
| Forget files you generated indirectly | Include all output: generated, compiled, derived files |
git add -A and then unstage what does not belong | git add with explicit paths |
| Bring along unmodified files "by accident" | git diff --cached --stat verifies what is actually staged |
