Stats
Actions
Tags
From rvanbaalen
Commit changes using micro commits with conventional commit messages. Analyzes git diff, groups related files, and proposes commits for approval. Supports interactive and non-interactive (background) modes. Use when the user wants to commit their changes.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rvanbaalen:commitThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Commit the current changes using micro commits with conventional commit messages.
Commit the current changes using micro commits with conventional commit messages.
Do NOT run any git commands, read any files, or spawn any agents before the mode is selected. The very first action in this skill is always mode selection — nothing else.
Check $ARGUMENTS first:
$ARGUMENTS is i → use Interactive mode$ARGUMENTS is ni → use Non-interactive modeAskUserQuestion to ask the user:Question: "How would you like to commit?"
Options:
Run the full interactive workflow described below (analyze, group, propose, commit, push).
Spawn a background Agent (use model: "sonnet" and run_in_background: true) with a prompt that instructs it to:
-u origin <branch>; if on main/master, do NOT push and mention it in the resultAfter dispatching the agent, inform the user: "Committing in the background — you'll be notified when it's done." Then stop — do not block the conversation.
When the background agent completes, summarize what it committed (and whether it pushed) to the user.
Run these in parallel to get the full picture:
git status — see untracked files and overall stategit diff — unstaged changes to tracked filesgit diff --cached — already staged changesgit log --oneline -10 — recent commit style for this repoIf there are no changes (nothing unstaged, staged, or untracked), tell the user there's nothing to commit and stop.
Analyze the changes and group files that belong together in a single commit. Each group should represent one logical change.
Grouping heuristics:
For each group, use the AskUserQuestion tool. Put the details in the question text itself so the user can read them clearly:
Question text should include:
Options:
For each approved group, stage only the specific files and commit:
git add <files>
git commit -m "<conventional-commit-message>"
For changes that need a longer explanation, use a commit body via heredoc:
git commit -m "$(cat <<'EOF'
feat(auth): add OAuth2 login flow
Adds Google and GitHub OAuth providers. Session tokens are stored
in encrypted cookies with a 24h TTL.
EOF
)"
Use a body when the "why" isn't obvious from the title alone — e.g., non-trivial refactors, workarounds, or architectural decisions. Most commits only need a title.
After all commits are made, use AskUserQuestion to ask if the user wants to push the branch.
Use conventional commits with scopes where applicable:
feat(scope): add new featurefix(scope): resolve bugrefactor(scope): restructure codetest(scope): add or update testsdocs(scope): update documentationchore(scope): maintenance taskMatch the scope style and conventions visible in the repo's recent git log. If the repo doesn't use scopes, omit them.
--no-verify)AskUserQuestion — never wait for freeform inputmain or master — only push feature/topic branchesnpx claudepluginhub rvanbaalen/skills --plugin commitGuides git commits with atomic change analysis, conventional commit messages, and interactive staging options. Flags non-atomic commits and suggests splits for better maintainability.
Executes git commits with conventional commit message analysis, intelligent staging, and message generation. Use when asked to commit changes or when /commit is invoked.
Analyzes uncommitted git changes, excludes ephemeral files like node_modules or build/, groups by purpose into atomic conventional commits, validates code, and optionally pushes.