git-commit ยท diff
git:20260122.e24be77 to git:20261010.7c7f02f
79 added, 77 removed. Audit A to A.
---
name: git-commit
- description: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping'
+ description: 'Use this skill when the user wants to make a Git commit or split changes into more than one commit. Also use it when the user types "/commit" or asks for a conventional commit. The skill examines the diff, stages the related files, writes a Conventional Commits message, and runs git commit. Do not use it when the user wants only a commit message and no commit. Do not use it to push, open a pull request, rebase, or change the commit history.'
license: MIT
- allowed-tools: Bash
+ compatibility: 'Requires Git. The `--resolved` option of `git add` requires Git 2.56 or later.'
+ allowed-tools: shell(git:*)
---
# Git Commit with Conventional Commits
- ## Overview
+ Make Git commits that follow the [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) specification. Get the type, the scope, and the summary from the diff.
- Create standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.
+ ## Message Format
- ## Conventional Commit Format
+ ```text
+ <type>(<scope>): <summary>
+ <body>
+
+ <footer>
```
- <type>[optional scope]: <description>
- [optional body]
+ - The scope, the body, and the footer are optional. Without a scope, write `<type>: <summary>`.
+ - Write the summary in the imperative mood: "add", not "added" or "adds".
+ - Keep the first line at 72 characters or less. Do not put a period at the end.
+ - In the body, tell what changed and why.
+ - Write each footer as `Token: value`, for example `Refs: #456` or `Closes: #123`. In a token, use `-` in place of a space.
- [optional footer(s)]
- ```
+ ## Types
- ## Commit Types
+ Conventional Commits defines only `feat` and `fix`. The other types come from the Angular convention ([`@commitlint/config-conventional`](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)). If the repository has its own list, use that list.
- | Type | Purpose |
- | ---------- | ------------------------------ |
- | `feat` | New feature |
- | `fix` | Bug fix |
- | `docs` | Documentation only |
- | `style` | Formatting/style (no logic) |
- | `refactor` | Code refactor (no feature/fix) |
- | `perf` | Performance improvement |
- | `test` | Add/update tests |
- | `build` | Build system/dependencies |
- | `ci` | CI/config changes |
- | `chore` | Maintenance/misc |
- | `revert` | Revert commit |
+ | Type | Use it for |
+ | ---------- | ---------------------------------------------- |
+ | `feat` | A new feature |
+ | `fix` | A bug fix |
+ | `docs` | Documentation only |
+ | `style` | Formatting only, with no change to the logic |
+ | `refactor` | A code change that is not a feature or a fix |
+ | `perf` | A performance improvement |
+ | `test` | New or changed tests |
+ | `build` | The build system or the dependencies |
+ | `ci` | The CI configuration |
+ | `chore` | Other maintenance |
+ | `revert` | A revert of an earlier commit |
## Breaking Changes
- ```
- # Exclamation mark after type/scope
- feat!: remove deprecated endpoint
+ Put `!` before the colon, or add a `BREAKING CHANGE:` footer. Write the token in uppercase. `BREAKING-CHANGE:` is also correct.
- # BREAKING CHANGE footer
- feat: allow config to extend other configs
+ ```text
+ feat(api)!: remove the v1 endpoints
- BREAKING CHANGE: `extends` key behavior changed
+ BREAKING CHANGE: Clients must use the v2 endpoints.
```
## Workflow
- ### 1. Analyze Diff
+ ### 1. Read the repository rules
- ```bash
- # If files are staged, use staged diff
- git diff --staged
+ Find the commit rules before you write a message:
- # If nothing staged, use working tree diff
- git diff
+ - A commitlint configuration, for example `commitlint.config.js` or `.commitlintrc.json`.
+ - `CONTRIBUTING.md`.
+ - The recent messages: `git log --oneline -10`.
- # Also check status
+ If a repository rule is different from this skill, use the repository rule.
+
+ ### 2. Examine the changes
+
+ ```bash
git status --porcelain
+ git diff --staged
+ git diff
```
- ### 2. Stage Files (if needed)
-
- If nothing is staged or you want to group changes differently:
+ If there are no changes, tell the user. Do not make an empty commit.
- ```bash
- # Stage specific files
- git add path/to/file1 path/to/file2
+ ### 3. Stage the files
- # Stage by pattern
- git add *.test.*
- git add src/components/*
+ Put one logical change in each commit. If the staged files contain more than one change, stage only the files for one change:
- # Interactive staging
- git add -p
+ ```bash
+ git add -- path/to/file1 path/to/file2
+ git add -- '*.test.*'
+ git add -- src/components/
```
- **Never commit secrets** (.env, credentials.json, private keys).
+ - Put a glob in quotes. Without quotes, the shell expands the glob and does not find the files in subdirectories.
+ - Do not use `git add -p` or `git add -i`. These commands wait for input from a person.
+ - After you resolve a merge conflict, use `git add --resolved`. This command stages only the resolved files. If a file still has conflict markers, the command stops.
+ - Examine the list of staged files with `git diff --staged --name-only`. Do not commit secrets, for example `.env` files, `credentials.json`, or private keys.
- ### 3. Generate Commit Message
+ ### 4. Write the message
- Analyze the diff to determine:
+ Get each part from the diff:
- - **Type**: What kind of change is this?
- - **Scope**: What area/module is affected?
- - **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars)
+ - **Type**: The kind of change.
+ - **Scope**: The module or the area that the change affects.
+ - **Summary**: What changed, in one line.
- ### 4. Execute Commit
+ ### 5. Commit
+ Give each paragraph with a different `-m` option. Git puts a blank line between the paragraphs. This command works in Bash, PowerShell, and other shells.
+
```bash
- # Single line
- git commit -m "<type>[scope]: <description>"
+ git commit -m "feat(auth): add token refresh"
+ git commit -m "fix(parser): accept empty input" -m "An empty file caused a crash." -m "Closes: #123"
+ ```
- # Multi-line with body/footer
- git commit -m "$(cat <<'EOF'
- <type>[scope]: <description>
+ For a long message, write the message to a temporary file. Then run `git commit -F <file>`.
- <optional body>
+ ### 6. Make sure that the commit is correct
- <optional footer>
- EOF
- )"
+ ```bash
+ git log -1 --stat
+ git status --porcelain
```
- ## Best Practices
-
- - One logical change per commit
- - Present tense: "add" not "added"
- - Imperative mood: "fix bug" not "fixes bug"
- - Reference issues: `Closes #123`, `Refs #456`
- - Keep description under 72 characters
-
- ## Git Safety Protocol
+ ## Safety Rules
- - NEVER update git config
- - NEVER run destructive commands (--force, hard reset) without explicit request
- - NEVER skip hooks (--no-verify) unless user asks
- - NEVER force push to main/master
- - If commit fails due to hooks, fix and create NEW commit (don't amend)
+ - Do not change the Git configuration.
+ - Do not use `--no-verify` unless the user tells you to. Hooks can be in `.git/hooks` or in the Git configuration.
+ - If a hook fails, Git does not make the commit. Fix the problem, stage the files again, and run the same `git commit` command again. Do not use `--amend`, because it changes the previous commit.
+ - Do not change the commit history unless the user tells you to. Do not use `git reset --hard`, `git rebase`, or the experimental `git history` command.
+ - Do not push unless the user tells you to. Do not force push to the default branch.