commit

name	commit
description	Stage and commit changes with conventional commits
effort	low
allowed-tools	Bash(git status *), Bash(git diff *), Bash(git log *), Bash(git add *), Bash(git commit *), Bash(echo *), Read, Glob, Grep

Pre-fetched context

!git status --short !git diff --stat

Instructions

Commit changes quickly. Do not summarize after — move on immediately.

1. Run git diff HEAD and git log --oneline -5. Use HEAD, not a bare git diff — a bare git diff shows only unstaged changes and would miss anything already staged (before the first commit HEAD doesn't exist, so fall back to git diff --cached). No git diff surfaces untracked files, so Read any ?? files from status — you need their contents both to write an accurate message and to catch secrets.
2. Split changes into logical commits. Default to splitting — only combine when changes are genuinely coupled (one is meaningless without the other). Classify each changed file/hunk by its concern:
   • Different scope (e.g., zsh vs vim vs tmux) → separate commits
   • Different intent (e.g., bug fix vs new feature vs refactor vs docs) → separate commits
   • Structural cleanup mixed with behavioral change → separate commits (tidy first, then behavior)
   • If unsure whether to split, split. Smaller commits are always easier to review and revert.
3. For each commit: git add <explicit paths> → commit. Run git diff --cached --stat first only when the staged set could differ from intent — i.e. when splitting into multiple commits (a path meant for a later commit could leak in) or when staging non-deterministically (git add -A/./globs). For a single commit staged by explicit paths the result is deterministic, so skip the check and commit directly.
4. Message: Conventional Commits (type(scope): description), English only (always, regardless of the user's language), imperative. Match repo style if one exists.

   • Add a body that briefly explains why the change was made and any relevant background. Keep it concise — just enough for a future reader to understand the motivation without re-reading the diff.

   • Omit the body only when the subject line alone is self-explanatory (e.g., fixing a typo).

   • Do not append the Claude session URL / Claude-Session: trailer to the commit message.

   • For a multi-line message, feed it through a quoted heredoc into git commit -F - (stdin) so backticks, $, and quotes stay literal — no escaping, and no $() subshell (which triggers permission prompts):

     git commit -F - <<'COMMIT_MSG_EOF'
     type(scope): subject
     
     Body explaining why.
     COMMIT_MSG_EOF
     

5. Don't block — proceed with a safe default and report. This skill may run autonomously, so do not stop to ask. Make the call yourself: split conservatively when grouping is unclear; exclude generated files unless they're clearly meant to be committed. Secrets are the exception that still needs care, but not a halt: if a change looks like a real credential/token/key, do not stage that file — commit the rest and flag the suspect file prominently in your reply so the human can resolve it. Never commit a suspected secret and never block waiting for confirmation.