git-commit_skill

Overview

This skill helps create conventional commits for the current repository changes. It groups related changes into logical commits, stages and commits every file, and verifies the working directory is clean afterward. It enforces branch safety by moving work off protected branches when needed.

How this skill works

The skill inspects the working tree and diff summary to identify modified, added, and deleted files. It enforces rules: create a feature branch if on dev/staging/main, partition files into conventional-commit groups, stage and commit each group, and finally run git status to confirm no uncommitted changes remain. It never stashes or excludes files and avoids bypassing hooks or checks.

When to use it

• When you have local changes that need to be committed with conventional commit messages
• Before pushing to a shared branch to ensure a clean history and complete commits
• When working on dev, staging, or main so changes are moved to a feature branch
• When you must ensure no files are left unstaged or uncommitted
• When automated checks and pre-commit hooks must not be bypassed

Best practices

• Always create a feature branch if your current branch is dev, staging, or main
• Group related file changes into a single conventional commit type (feat/fix/docs/etc.)
• Write concise, descriptive commit messages that follow conventional commit format
• Stage and commit every changed file; do not stash or leave files out
• Never use --no-verify or otherwise skip tests and quality checks

Example use cases

• You modified implementation and tests: create a fix: commit for the bug fix and a test: commit for new tests
• You updated README and configuration: create a docs: commit for docs and a chore: commit for config maintenance
• You changed formatting across many files: create a style: commit that includes all formatting changes
• You are on main with local changes: create a feature branch named after the change and commit there