| description | Generate conventional commit with staged changes |
| name | conventional-commit |
| model | sonnet |
| disable-model-invocation | true |
Instructions
You are committing staged changes in the current git repository. Follow these rules exactly.
Context Analysis
Run these commands to understand the current state:
git status --porcelain
git diff --cached --name-only
git diff --cached
git log --oneline -5
MANDATORY: No AI attribution
NEVER include any of the following in the commit message, body, footer, or trailers:
Co-Authored-By trailers mentioning Claude, Anthropic, or any AI
- Any mention of Claude, Anthropic, AI, or LLM anywhere in the commit
- Any
Signed-off-by, Generated-by, or similar trailers referencing AI
Violating this rule makes the commit invalid. Double-check before executing.
MANDATORY: Stop immediately if a pre-commit hook fails
If git commit fails because a pre-commit hook rejected it (lint, knip, type-check, prettier, tests, etc.):
- STOP immediately. Do not retry the commit.
- Do NOT edit any source file to get past the hook — no lint suppressions, no
knip: off/@knip/ignore comments, no deleting exports, no --fix, no touching unrelated files.
- Do NOT stage anything (
git add is still forbidden).
- Report the hook failure verbatim (the failing tool + its error output) and hand control back to the user.
Fixing hook failures is the user's call, not yours. Your job is only to compose the message and commit what is already staged.
Your Task
- Analyze only the staged changes (
git diff --cached) to understand what was modified
- NEVER stage additional files. Do not run
git add. Only commit what the user has already staged.
- If nothing is staged, inform the user and stop — do not stage files on their behalf
- Generate a conventional commit message (feat, fix, docs, etc.) based solely on staged changes
- Make the message descriptive but concise
- Execute
git commit with the generated message — no Co-Authored-By or AI trailers
- If a pre-commit hook fails, follow the Stop immediately rule above — do not work around it
- Return the commit hash and a short summary (or the hook failure if it was blocked)
Conventional Commit Messages
See how a minor change to your commit message style can make a difference.
git commit -m "<type>(<optional scope>): <description>" \
-m"<optional body>" \
-m"<optional footer>"
Commit Message Formats
General Commit
<type>(<optional scope>): <description>
empty line as separator
<optional body>
empty line as separator
<optional footer>
Initial Commit
chore: init
Merge Commit
Merge branch '<branch name>'
Follows default git merge message
Revert Commit
Revert "<reverted commit subject line>"
Follows default git revert message
Types
- Changes relevant to the API or UI:
feat Commits that add, adjust or remove a new feature to the API or UI
fix Commits that fix an API or UI bug of a preceded feat commit
refactor Commits that rewrite or restructure code without altering API or UI behavior
perf Commits are special type of refactor commits that specifically improve performance
style Commits that address code style (e.g., white-space, formatting, missing semi-colons) and do not affect
application behavior
test Commits that add missing tests or correct existing ones
docs Commits that exclusively affect documentation
build Commits that affect build-related components such as build tools, dependencies, project version, CI/CD
pipelines, ...
ops Commits that affect operational components like infrastructure, deployment, backup, recovery procedures, ...
chore Miscellaneous commits e.g. modifying .gitignore, ...
claude Commits that affect .claude/
Scopes
The scope provides additional contextual information.
- The scope is an optional part
- Allowed scopes vary and are typically defined by the specific project
- Do not use issue identifiers as scopes
Breaking Changes Indicator
- A commit that introduce breaking changes must be indicated by an
! before the : in the subject line e.g.
feat(api)!: remove status endpoint
- Breaking changes should be described in the commit footer section, if
the commit description isn't sufficiently informative
Description
The description contains a concise description of the change.
- The description is a mandatory part
- Use the imperative, present tense: "change" not "changed" nor "changes"
- Think of
This commit will... or This commit should...
- Do not capitalize the first letter
- Do not end the description with a period (
.)
- I case of breaking changes also see breaking changes indicator
Body
The body should include the motivation for the change and contrast this with previous behavior.
- The body is an optional part
- Use the imperative, present tense: "change" not "changed" nor "changes"
Footer
The footer should contain issue references and information about Breaking Changes
- The footer is an optional part, except if the commit introduce breaking changes
- Optionally reference issue identifiers (e.g.,
Closes #123, Fixes JIRA-456)
- Breaking Changes must start with the word
BREAKING CHANGE:
- For a single line description just add a space after
BREAKING CHANGE:
- For a multi line description add two new lines after
BREAKING CHANGE:
Versioning
- If your next release contains commit with...
- Breaking Changes incremented the major version
- API relevant changes (
feat or fix) incremented the minor version
- Else increment the patch version
Examples
-
feat: add email notifications on new direct messages
-
feat(shopping cart): add the amazing button
-
feat;: remove ticket list endpoint
refers to JIRA-1337
BREAKING CHANGE: ticket endpoints no longer supports list all entities.
-
fix(shopping-cart): prevent order an empty shopping cart
-
fix(api): fix wrong calculation of request body checksum
-
fix: add missing parameter to service call
The error occurred due to <reasons>.
-
perf: decrease memory footprint for determine unique visitors by using HyperLogLog
-
build: update dependencies
-
build(release): bump version to 1.0.0
-
refactor: implement fibonacci number calculation as recursion
-
style: remove empty line