commit

ZhuMon's avatarfrom ZhuMon

Smart commit creation with conventional commits. Use when user says "commit" or requests committing changes. Handles staged file detection, suggests splits for multi-concern changes, and applies proper commit format without emoji prefixes.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 19, 2025
[Developer Tools]

When & Why to Use This Skill

This Claude skill automates the creation of professional Git commits by strictly adhering to conventional commit standards. It intelligently analyzes diffs to detect staged changes, suggests logical splits for multi-concern updates, and ensures DCO compliance with automatic sign-offs, helping developers maintain a clean, readable, and standardized project history.

Use Cases

  • Standardizing repository history: Automatically generating 'feat', 'fix', and 'chore' commits that follow industry-standard formatting for better changelog generation.
  • Atomic commit management: Analyzing large changesets and suggesting splits into multiple logical commits to improve code review efficiency and rollback safety.
  • Open-source contribution: Ensuring all commits meet Developer Certificate of Origin (DCO) requirements by automatically applying the --signoff flag.
  • Workflow optimization: Handling the detection of staged vs. unstaged files and enforcing imperative mood and character limits without manual intervention.
  • Breaking change documentation: Using the '!' syntax and structured body footers to clearly communicate breaking changes to the rest of the engineering team.
namecommit
descriptionSmart commit creation with conventional commits. Use when user says "commit" or requests committing changes. Handles staged file detection, suggests splits for multi-concern changes, and applies proper commit format without emoji prefixes.

Commit Skill

Creates well-formatted commits following conventional commit standards.

Core Features

  • Staged vs unstaged detection - commits only staged files when present
  • Split suggestions - analyzes diffs for multiple logical changes
  • Conventional commits format: <type>: <description>
  • Pre-commit hook integration
  • Always --signoff for DCO compliance

Process

1. Analyze Changes

git status --short

# Prefer staged files if any exist
if ! git diff --staged --quiet; then
  git diff --staged --stat
else
  git diff HEAD --stat
fi

2. Multi-Concern Detection

Suggest split if:

  • Different patterns: src/ + test/ + docs/
  • Mixed types: feat + fix + docs
  • Unrelated concerns: auth logic + UI styling
  • Large changeset: >500 lines

Ask user:

Multiple concerns detected:
1. Auth changes (src/auth/*)
2. UI updates (src/components/*)
3. Docs (README.md)

Split into 3 commits?
- feat: add JWT authentication
- style: update login UI
- docs: update auth documentation

[split/all]

3. Create Commit

Format: <type>: <description>

Rules:

  • Imperative mood ("add" not "added")
  • First line <72 chars
  • Atomic (single purpose)
  • Use body for "why" if needed
git commit --signoff -m "<type>: <description>"

Commit Body Conventions

When changes need more context, add a body:

git commit --signoff -m "$(cat <<'EOF'
<type>: <description>

<body>
EOF
)"

When to Include Body

  • Multiple files changed
  • Non-obvious reasoning
  • Breaking changes
  • Related issues/PRs

Body Format

  • Blank line after subject
  • Wrap at 72 chars
  • Explain "why" not "what"
  • Use bullet points for lists

Body Example

feat: add user authentication

- Implement JWT token validation
- Add protected routes middleware
- Include refresh token support

Closes #123

Breaking Changes

Add exclamation mark (!) after type for breaking changes:

feat!: change API response format

BREAKING CHANGE: Response now returns { data, meta }
instead of flat object. Update all API consumers.

4. Handle --no-verify

If user requests --no-verify:

Warning: Requested to skip pre-commit hooks.
Bypasses: linting, tests, formatting
Reason: [ask user]
Approve? [yes/no]

Only proceed if confirmed.

Commit Types

Type Use Case
feat New feature
fix Bug fix
docs Documentation
style Formatting, styling
refactor Code restructure
perf Performance
test Tests
chore Build/tools
ci CI/CD
security Security fix
build Build system
revert Revert changes
wip Work in progress

Split Examples

Bad - Mixed concerns

+ src/auth/login.ts (feat)
+ src/components/Button.css (style)
+ README.md (docs)

Split into: 3 separate commits

Good - Single concern

+ src/auth/login.ts
+ src/auth/middleware.ts
+ tests/auth.test.ts

One commit: feat: add authentication

Critical Rules

NEVER

  • Add Claude signature to commits
  • Commit without checking staged status
  • Skip split suggestions for multi-concern
  • Use past tense ("added" -> "add")
  • Make first line >72 chars
  • Bypass hooks without asking

ALWAYS

  • Use --signoff flag
  • Analyze diff before commit
  • Suggest splits when appropriate
  • Use imperative mood
  • Pick correct type
  • Ask approval for --no-verify