From git-helper
This skill should be used when the user invokes /git-helper:generate-commit, or asks to "generate a commit message", "write a commit for me", "what should my commit message be", "help me commit my changes", or "suggest a commit message". Analyzes staged changes, unstaged diffs, git status, and recent log history using conventional commit format to produce a properly formatted subject, body, and optional footer.
How this skill is triggered — by the user, by Claude, or both
Slash command
/git-helper:generate-commitThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate a conventional commit message by analyzing the current git context. Display the result for the user to copy and run manually — never execute the commit automatically.
Generate a conventional commit message by analyzing the current git context. Display the result for the user to copy and run manually — never execute the commit automatically.
Check if .claude/git-helper.local.md exists. If it does, parse the YAML frontmatter to get default_scope:
SETTINGS=".claude/git-helper.local.md"
if [ -f "$SETTINGS" ]; then
FRONTMATTER=$(sed -n '/^---$/,/^---$/{ /^---$/d; p; }' "$SETTINGS")
DEFAULT_SCOPE=$(echo "$FRONTMATTER" | grep '^default_scope:' | sed 's/default_scope: *//' | sed 's/^"\(.*\)"$/\1/')
fi
Use default_scope as a fallback when scope cannot be inferred from the diff (Step 5).
Run the context script, passing any user-supplied file paths as arguments:
# No file filter — analyze all changes
bash "$CLAUDE_PLUGIN_ROOT/scripts/collect-context.sh"
# One file
bash "$CLAUDE_PLUGIN_ROOT/scripts/collect-context.sh" "src/auth/login.ts"
# Multiple files
bash "$CLAUDE_PLUGIN_ROOT/scripts/collect-context.sh" "src/auth/login.ts" "src/auth/logout.ts"
$CLAUDE_PLUGIN_ROOT is set by the plugin runtime to the plugin's root directory.
The [file1 file2 ...] arguments are file paths that limit the diff output to those specific files. When provided, the script runs git diff -- <files> and git diff --cached -- <files> instead of showing all changes. Omit them to analyze all staged/unstaged changes.
The script outputs labeled sections (headers use === delimiters):
=== GIT LOG (last 10 commits) === — tone and style reference=== GIT STATUS === — current working tree state=== GIT DIFF (unstaged) === — unstaged changes (filtered to files if provided)=== GIT DIFF STAGED === — staged changes (filtered to files if provided)=== FILE FILTER === — the file paths used as filter (only when files were passed)If both diffs are empty and status shows no changes, inform the user there is nothing to commit and stop.
Analyze the staged diff first (primary signal), then unstaged diff and status as supporting context. Select exactly one type from the table below:
| Type | When to use |
|---|---|
feat | New feature visible to the user (not a build-script feature) |
fix | Bug fix visible to the user (not a build-script fix) |
docs | Documentation changes only (e.g., README.md) |
refactor | Production code restructured without behavior change |
test | Tests added or refactored; no production code changed |
chore | Non-production tasks (grunt tasks, tooling, etc.) |
ci | CI configuration files or scripts changed |
perf | Performance improvement |
revert | Reverting a previous commit |
bump | Dependency version update |
Tie-breaking rules:
feat and fix take priority over refactor when in doubtMark as a breaking change if any of the following are true:
BREAKING CHANGEInfer scope from the changed file paths (e.g., auth from src/auth/login.ts, api from routes/api/, ui from components/). If scope cannot be inferred and default_scope is set in .claude/git-helper.local.md, use that as the fallback. Omit scope entirely if changes are too broad or cross-cutting.
Scope must be lowercase, no spaces, no special characters.
Format: <type>[(<scope>)][!]: <description>
Rules for the description:
Examples:
feat(auth): add OAuth2 login support
fix(api): handle null response from payment gateway
refactor: extract validation logic into separate module
feat!: remove deprecated v1 endpoints
Include a commit body when:
Separate body from subject with a blank line. Wrap at 72 characters.
If a breaking change was detected, append:
BREAKING CHANGE: <description of what broke and how to migrate>
Present the complete commit message in a code block:
feat(auth): add OAuth2 login support
Allow users to authenticate via Google and GitHub OAuth2 providers.
Token storage uses existing session infrastructure.
BREAKING CHANGE: removed /api/v1/auth/basic endpoint. Use /api/v2/auth instead.
Then show the ready-to-run git command:
git commit -m "feat(auth): add OAuth2 login support"
For multi-line messages (body or BREAKING CHANGE footer), show the heredoc form:
git commit -m "$(cat <<'EOF'
feat(auth): add OAuth2 login support
Allow users to authenticate via Google and GitHub OAuth2 providers.
Token storage uses existing session infrastructure.
BREAKING CHANGE: removed /api/v1/auth/basic endpoint. Use /api/v2/auth instead.
EOF
)"
git add). Still generate the message based on unstaged diff so the user can review it before staging.refactor (formatting changes with no logic change).chore: merge <branch> unless the merge introduces a feature or fix.revert: revert "<original subject>" and reference the reverted commit hash in the body.references/commit-types.md — Detailed type selection guide with examples for ambiguous casesCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub sembraniteam/claude-plugins --plugin git-helper