Git Commit Helper Skill

A Claude Code skill for analyzing staged changes and generating well-structured, conventional commit messages — following commit message standards, semantic versioning implications, and team conventions.

When to Use This Skill

Choose this skill when:

• Committing changes and want a clear, descriptive commit message
• Following conventional commit format (feat, fix, docs, etc.)
• Working on a team with commit message standards
• Generating commit messages for complex multi-file changes
• Understanding the semantic versioning impact of your changes

Consider alternatives when:

• You need to push changes after committing (use a git push skill)
• You need to create a PR (use a branch finishing skill)
• You need to manage branches (use git directly)

Quick Start

Copy
# Add to your Claude Code project
claude mcp add git-commit-helper

# Stage changes and generate commit message
claude "commit these changes with an appropriate message"

# Generate message without committing
claude "suggest a commit message for my staged changes"

Copy
# View staged changes for context
git diff --staged

# Common conventional commit prefixes
# feat:     New feature (MINOR version bump)
# fix:      Bug fix (PATCH version bump)
# docs:     Documentation changes
# style:    Formatting, no code change
# refactor: Code change that neither fixes nor adds
# perf:     Performance improvement
# test:     Adding or updating tests
# chore:    Build process, dependency updates

Core Concepts

Conventional Commit Format

Prefix	SemVer Impact	Example
feat:	Minor (1.x.0)	feat: add user export to CSV
fix:	Patch (1.0.x)	fix: resolve login redirect loop
feat!:	Major (x.0.0)	feat!: change auth API response format
docs:	None	docs: add API authentication guide
refactor:	None	refactor: extract validation into shared module
perf:	Patch	perf: add database query index for user lookup
test:	None	test: add integration tests for payment flow
chore:	None	chore: update eslint to v9

Commit Message Structure

feat(auth): add OAuth2 social login providers

Add Google and GitHub as OAuth2 login options alongside existing
email/password authentication. Includes:
- OAuth2 provider configuration in auth service
- Social login buttons on sign-in and sign-up pages
- Account linking for existing users with matching email

Closes #234

Message Generation from Diff

Copy
# The skill analyzes staged changes to generate messages

# Example: Multiple files changed
# Modified: src/services/authService.ts (added OAuth methods)
# Modified: src/pages/login.tsx (added social login buttons)
# Added:    src/config/oauth.ts (OAuth provider config)
# Modified: src/types/auth.ts (added OAuth types)

# Generated message:
# feat(auth): add OAuth2 social login with Google and GitHub
#
# Implement OAuth2 authentication flow supporting Google and GitHub
# providers. Add provider configuration, social login UI components,
# and automatic account linking for matching emails.

Configuration

Parameter	Type	Default	Description
format	string	"conventional"	Commit format: conventional, angular, simple
max_subject_length	number	72	Maximum characters for subject line
include_body	boolean	true	Generate multi-line body for complex changes
include_scope	boolean	true	Add scope (e.g., feat(auth):)
include_breaking	boolean	true	Flag breaking changes with !
auto_stage	boolean	false	Auto-stage unstaged changes
sign_off	boolean	false	Add Signed-off-by trailer
co_authors	array	[]	Add Co-authored-by trailers

Best Practices

1. Write the subject line as an imperative sentence — "add user export" not "added user export" or "adding user export"; this matches git's own convention ("Merge branch", "Revert commit").

2. Keep the subject under 72 characters — this ensures the full message is visible in git log --oneline, GitHub PR lists, and notification emails without truncation.

3. Separate subject from body with a blank line — git and GitHub tools treat the first line as the commit title; a blank line after it ensures the body is formatted correctly in all views.

4. Explain why, not what, in the commit body — the diff shows what changed; the body should explain why the change was necessary and any context that future readers will need.

5. Reference issue numbers in the commit — add Closes #123 or Refs #456 to link commits to issues; this creates traceability and auto-closes issues when merged.

Common Issues

Commit message doesn't match the actual changes — The generated message is based on the staged diff. If you staged unrelated changes together, the message will try to summarize unrelated work. Stage and commit related changes separately.

Breaking changes aren't flagged — The skill detects API signature changes and removed exports, but may miss behavioral breaking changes. Always manually add ! and a BREAKING CHANGE: footer when you know consumers will be affected.

Scope is too broad or too narrow — Use module or feature names for scope (auth, api, dashboard), not file names. If changes span multiple scopes, drop the scope entirely rather than using a vague one.