| name | git-smart-commit |
| description | Generate intelligent conventional commit messages from staged changes. Analyzes diffs, auto-detects scope and breaking changes, and commits with approval. |
Git Smart Commit
Generate a precise conventional commit message from the currently staged changes, then commit after user approval.
Steps
1. Gather Context
Run these commands to understand the staged changes and recent commit style:
git diff --cached --stat
git diff --cached
git log --oneline -10
If there are no staged changes, inform the user and suggest they stage files first (git add <files>). Do not proceed with an empty diff.
2. Analyze the Diff
Examine every file in the staged diff. Determine:
- What changed: New files, modified logic, deleted code, config changes, dependency updates.
- Why it changed: Infer intent from the nature of the change (new feature, bug fix, refactor, etc.).
- Scope: Derive scope from the file paths. Use the most specific meaningful directory or module name.
src/auth/login.ts -> scope is authtests/utils/parser.test.js -> scope is utilspackage.json only -> scope is deps.github/workflows/ci.yml -> scope is ci- Multiple unrelated scopes -> omit scope or use the dominant one.
- Breaking changes: Look for removed public APIs, renamed exports, changed function signatures, deleted fields, major dependency version bumps, or migration-requiring config changes.
3. Select Commit Type
Choose exactly one type based on priority:
| Type | When to use |
|---|
feat | New feature or capability added |
fix | Bug fix or correction |
docs | Documentation only changes |
refactor | Code restructuring with no behavior change |
perf | Performance improvement |
test | Adding or updating tests |
ci | CI/CD pipeline changes |
build | Build system or dependency changes |
chore | Maintenance tasks, tooling, config |
style | Formatting, whitespace, semicolons (no logic change) |
revert | Reverting a previous commit |
4. Compose the Commit Message
Follow this structure:
<type>(<scope>): <subject>
<body>
<footer>
Rules:
- Subject line: imperative mood, lowercase, no period, max 72 characters.
- Body (optional): Explain what and why, not how. Wrap at 80 characters. Include only if the subject alone is insufficient.
- Footer: Add
BREAKING CHANGE: <description> if breaking changes were detected. Reference issue numbers if visible in branch name or diff comments (e.g., Closes #42).
5. Present for Approval
Show the complete commit message to the user in a fenced code block. Ask:
Ready to commit with this message? (yes / edit / abort)
- If yes: Run
git commit -m "<message>" using a HEREDOC for multi-line messages.
- If edit: Ask the user what to change, revise, and re-present.
- If abort: Stop without committing.
6. Confirm
After committing, run git log --oneline -1 to confirm the commit was created and display the short hash and message.
Edge Cases
- Merge commits: Note that the staged changes are part of a merge and keep the message descriptive of the merge resolution.
- Large diffs (>500 lines): Summarize by file group rather than reading every line. Focus on the overall intent.
- Mixed concerns: If staged changes span multiple unrelated concerns, recommend the user split them into separate commits. Offer to help unstage files.
- Amend requests: If the user says "amend", use
git commit --amend but warn that this rewrites history.
