Smart git commit
Create well-formatted git commits with conventional commit format and emoji. Automatically runs pre-commit checks (lint, build, docs), analyzes changes, suggests splitting when appropriate, and generates emoji-prefixed conventional commit messages. Use when creating commits in any repository to ensure consistent, professional commit history.From its SKILL.md
npx -y skills add zlh-428/naruto-skills --skill smart-git-commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.1 KB, as published. Nobody here has run it
Smart Git Commit
Create well-formatted commits with conventional commit format and emoji: $ARGUMENTS
Quick Start
# Basic commit with auto-generated message
/smart-git-commit
# Provide custom message
/smart-git-commit "add user authentication"
# Skip pre-commit checks
/smart-git-commit --no-verify
# Amend last commit
/smart-git-commit --amend
Workflow
1. Pre-Commit Checks (Default)
Unless --no-verify is specified, automatically runs:
pnpm lint- Ensure code qualitypnpm build- Verify build succeedspnpm generate:docs- Update documentation
If checks fail, asks whether to proceed or fix issues first.
2. Stage Analysis
Checks git status to determine staged files:
- Files already staged: Only commits those files
- No files staged: Automatically stages all modified/new files
3. Change Analysis
Performs git diff --cached to understand changes and:
- Detects commit type (feat, fix, docs, refactor, etc.)
- Identifies if multiple distinct changes are present
- Suggests splitting when appropriate
4. Message Generation
Creates commit message in format: <emoji> <type>: <description>
See commit-types.md for full emoji/type reference.
Commit Types
| Type | Emoji | Description |
|---|---|---|
feat | β¨ | New feature |
fix | π | Bug fix |
docs | π | Documentation |
style | π | Formatting/style |
refactor | β»οΈ | Code refactoring |
perf | β‘οΈ | Performance |
test | β | Tests |
chore | π§ | Tooling, config |
ci | π | CI/CD |
Command Options
| Option | Description |
|---|---|
[message] | Custom commit description (optional) |
--no-verify | Skip pre-commit checks (lint, build, docs) |
--amend | Amend the previous commit |
Splitting Guidelines
Consider splitting when:
- Different concerns: Unrelated codebase areas
- Different types: Features + fixes + docs mixed
- File patterns: Source code vs documentation vs tests
- Size: Large changes clearer if broken down
See examples.md for splitting examples.
Examples
# Auto-generated from staged changes
/smart-git-commit
# Output: β¨ feat: add user authentication system
# Custom message
/smart-git-commit "resolve memory leak in parser"
# Output: π fix: resolve memory leak in parser
# Skip checks for quick fixes
/smart-git-commit --no-verify "typo fix"
# Output: βοΈ fix: typo fix
Best Practices
- Atomic commits: Each commit serves one purpose
- Present tense: "add feature" not "added feature"
- Concise: First line under 72 characters
- Review diff: Ensure message matches changes