Generating Smart Commits
Current State
!git diff --cached --stat
!git log --oneline -5
!git status --short
Overview
Analyze staged git changes and generate Conventional Commits messages with accurate type classification, scope detection, and breaking change identification. Supports feat, fix, docs, style, refactor, test, chore, perf, ci, and build types following the Conventional Commits 1.0.0 specification.
Prerequisites
- Git repository initialized in the working directory
- Changes staged via
git add (at least one staged file)
- Git user name and email configured (
git config user.name, git config user.email)
- Understanding of the project's commit message conventions (check recent history)
Instructions
- Run
git diff --cached --stat to get an overview of staged files and change volume
- Run
git diff --cached to examine the actual code changes in detail
- Classify the commit type based on the nature of changes:
feat: new functionality visible to usersfix: bug correctionrefactor: code restructuring without behavior changedocs: documentation onlytest: adding or updating testschore: build process, dependencies, or toolingperf: performance improvementci: CI/CD configuration changes
- Determine scope from the primary directory or module affected (e.g.,
auth, api, cli, db)
- Check for breaking changes: removed public APIs, changed function signatures, renamed exports, schema migrations
- Check recent commit history with
git log --oneline -10 to match the project's style conventions
- Construct the commit message:
type(scope): imperative description under 72 characters
- Add a body with bullet points explaining the "why" behind the change if the diff is non-trivial
- Append
BREAKING CHANGE: footer if applicable
Output
Conventional commit message following this format:
type(scope): imperative description
- Explanation of what changed and why
- Impact on existing functionality
BREAKING CHANGE: description (if applicable)
Error Handling
| Error |
Cause |
Solution |
No changes staged for commit |
Nothing added to staging area |
Run git add <files> to stage changes before generating the message |
Not a git repository |
Working directory is not inside a git repo |
Run git init or navigate to the repository root |
Ambiguous commit type |
Changes span multiple categories (feature + fix) |
Split into separate commits or use the primary intent as the type |
Scope unclear from file paths |
Changes touch many unrelated directories |
Use the most significant module or omit scope entirely |
Commit message exceeds 72 characters |
Description too verbose |
Shorten to the essential action; move details to the commit body |
Examples
- "Analyze my staged changes and generate a conventional commit message with the right type and scope."
- "Create a commit message for these changes, checking if there are any breaking changes in the API."
- "Generate a smart commit following this project's existing commit style (check the last 10 commits)."
Resources
1---
2name: generating-smart-commits-2
3description: |
4 Execute use when generating conventional commit messages from staged git changes. Trigger with phrases like "create commit message", "generate smart commit", "/commit-smart", or "/gc". Automatically analyzes changes to determine commit type (feat, fix, docs), identifies breaking changes, and formats according to conventional commit standards.
5allowed-tools: Read, Write, Edit, Grep, Glob, Bash(git:*)
6version: 1.0.0
7author: Jeremy Longshore <jeremy@intentsolutions.io>
8license: MIT
9compatible-with: claude-code, codex, openclaw
10tags: [devops, git, smart-commits]
11
12---
13
14# Generating Smart Commits
15
16## Current State
17!`git diff --cached --stat`
18!`git log --oneline -5`
19!`git status --short`
20
21## Overview
22
23Analyze staged git changes and generate Conventional Commits messages with accurate type classification, scope detection, and breaking change identification. Supports `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `perf`, `ci`, and `build` types following the Conventional Commits 1.0.0 specification.
24
25## Prerequisites
26
27- Git repository initialized in the working directory
28- Changes staged via `git add` (at least one staged file)
29- Git user name and email configured (`git config user.name`, `git config user.email`)
30- Understanding of the project's commit message conventions (check recent history)
31
32## Instructions
33
341. Run `git diff --cached --stat` to get an overview of staged files and change volume
352. Run `git diff --cached` to examine the actual code changes in detail
363. Classify the commit type based on the nature of changes:
37 - `feat`: new functionality visible to users
38 - `fix`: bug correction
39 - `refactor`: code restructuring without behavior change
40 - `docs`: documentation only
41 - `test`: adding or updating tests
42 - `chore`: build process, dependencies, or tooling
43 - `perf`: performance improvement
44 - `ci`: CI/CD configuration changes
454. Determine scope from the primary directory or module affected (e.g., `auth`, `api`, `cli`, `db`)
465. Check for breaking changes: removed public APIs, changed function signatures, renamed exports, schema migrations
476. Check recent commit history with `git log --oneline -10` to match the project's style conventions
487. Construct the commit message: `type(scope): imperative description under 72 characters`
498. Add a body with bullet points explaining the "why" behind the change if the diff is non-trivial
509. Append `BREAKING CHANGE:` footer if applicable
51
52## Output
53
54Conventional commit message following this format:
55
56```
57type(scope): imperative description
58
59- Explanation of what changed and why
60- Impact on existing functionality
61
62BREAKING CHANGE: description (if applicable)
63```
64
65## Error Handling
66
67| Error | Cause | Solution |
68|-------|-------|---------|
69| `No changes staged for commit` | Nothing added to staging area | Run `git add <files>` to stage changes before generating the message |
70| `Not a git repository` | Working directory is not inside a git repo | Run `git init` or navigate to the repository root |
71| `Ambiguous commit type` | Changes span multiple categories (feature + fix) | Split into separate commits or use the primary intent as the type |
72| `Scope unclear from file paths` | Changes touch many unrelated directories | Use the most significant module or omit scope entirely |
73| `Commit message exceeds 72 characters` | Description too verbose | Shorten to the essential action; move details to the commit body |
74
75## Examples
76
77- "Analyze my staged changes and generate a conventional commit message with the right type and scope."
78- "Create a commit message for these changes, checking if there are any breaking changes in the API."
79- "Generate a smart commit following this project's existing commit style (check the last 10 commits)."
80
81## Resources
82
83- Conventional Commits specification: https://www.conventionalcommits.org/en/v1.0.0/
84- Angular commit guidelines: https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit
85- Git commit best practices: https://cbea.ms/git-commit/
jeremylongshore