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.

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.

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 auth
- tests/utils/parser.test.js -> scope is utils
- package.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.

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

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).

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.

After committing, run git log --oneline -1 to confirm the commit was created and display the short hash and message.

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.