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.
1---2name: git-smart-commit3description: Generate intelligent conventional commit messages from staged changes. Analyzes diffs, auto-detects scope and breaking changes, and commits with approval.4---56# Git Smart Commit78Generate a precise conventional commit message from the currently staged changes, then commit after user approval.910## Steps1112### 1. Gather Context1314Run these commands to understand the staged changes and recent commit style:1516```17git diff --cached --stat18git diff --cached19git log --oneline -1020```2122If there are no staged changes, inform the user and suggest they stage files first (`git add <files>`). Do not proceed with an empty diff.2324### 2. Analyze the Diff2526Examine every file in the staged diff. Determine:2728- **What changed**: New files, modified logic, deleted code, config changes, dependency updates.29- **Why it changed**: Infer intent from the nature of the change (new feature, bug fix, refactor, etc.).30- **Scope**: Derive scope from the file paths. Use the most specific meaningful directory or module name.31 - `src/auth/login.ts` -> scope is `auth`32 - `tests/utils/parser.test.js` -> scope is `utils`33 - `package.json` only -> scope is `deps`34 - `.github/workflows/ci.yml` -> scope is `ci`35 - Multiple unrelated scopes -> omit scope or use the dominant one.36- **Breaking changes**: Look for removed public APIs, renamed exports, changed function signatures, deleted fields, major dependency version bumps, or migration-requiring config changes.3738### 3. Select Commit Type3940Choose exactly one type based on priority:4142| Type | When to use |43|------------|-------------|44| `feat` | New feature or capability added |45| `fix` | Bug fix or correction |46| `docs` | Documentation only changes |47| `refactor` | Code restructuring with no behavior change |48| `perf` | Performance improvement |49| `test` | Adding or updating tests |50| `ci` | CI/CD pipeline changes |51| `build` | Build system or dependency changes |52| `chore` | Maintenance tasks, tooling, config |53| `style` | Formatting, whitespace, semicolons (no logic change) |54| `revert` | Reverting a previous commit |5556### 4. Compose the Commit Message5758Follow this structure:5960```61<type>(<scope>): <subject>6263<body>6465<footer>66```6768Rules:69- **Subject line**: imperative mood, lowercase, no period, max 72 characters.70- **Body** (optional): Explain *what* and *why*, not *how*. Wrap at 80 characters. Include only if the subject alone is insufficient.71- **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`).7273### 5. Present for Approval7475Show the complete commit message to the user in a fenced code block. Ask:7677> Ready to commit with this message? (yes / edit / abort)7879- If **yes**: Run `git commit -m "<message>"` using a HEREDOC for multi-line messages.80- If **edit**: Ask the user what to change, revise, and re-present.81- If **abort**: Stop without committing.8283### 6. Confirm8485After committing, run `git log --oneline -1` to confirm the commit was created and display the short hash and message.8687## Edge Cases8889- **Merge commits**: Note that the staged changes are part of a merge and keep the message descriptive of the merge resolution.90- **Large diffs (>500 lines)**: Summarize by file group rather than reading every line. Focus on the overall intent.91- **Mixed concerns**: If staged changes span multiple unrelated concerns, recommend the user split them into separate commits. Offer to help unstage files.92- **Amend requests**: If the user says "amend", use `git commit --amend` but warn that this rewrites history.
xmqywx