| name | commit |
| description | Write a commit message for the pending changes in this repository, in the project's established style. Use when the user asks for a commit message, asks to commit, or types /commit. Optionally creates the commit. |
Commit message
Produce a commit message for the current changes that reads like the rest of this repository's history.
Gather first
Run these before writing anything:
git status --short
git diff --staged --stat && git diff --stat
git log -8 --format='%s%n%b%n---'
- If anything is staged, describe only the staged changes. Otherwise describe the whole working tree.
- Read the actual diff of the non-trivial files, not just the stat. A message derived from filenames alone describes the files, not the change - that is the failure mode to avoid.
- If
docs/changelog.md changed, its entry is the clearest statement of user-visible intent. Use it, but do not copy its wording verbatim.
Style
The git log output above is the authority. As of this writing the house style is:
Subject line
- Imperative mood, capitalized, no trailing period:
Fix rsync progress flag and log handling
- No
feat: / fix: / conventional-commit prefix, no scope brackets, no emoji
- Aim for under ~65 characters
- Name the change, not the files touched
Body
- One prose paragraph, roughly 2 to 5 sentences. No bullet lists.
- Say what changed and why it mattered. Behavior before and after beats a list of edits.
- Backticks for identifiers, flags, and paths:
`--info=progress2`, `src/lib/utils.ts`
- Mention added test coverage and the changelog entry when they are part of the change - the history consistently does
- Blank line between subject and body
Typography (project rule, see the root CLAUDE.md)
- No em dashes. Use a hyphen.
- No semicolons. End sentences with a period.
- English.
Scope check
If the diff contains two or more genuinely unrelated changes, say so and propose a split: one subject line per commit plus which paths belong to each. Do not silently bundle them under a vague subject like "Various fixes". A single coherent change that touches many files is still one commit.
Output
Present the subject and body as copyable text. Then ask whether to create the commit - do not commit unprompted.
If the user says yes:
- Stage only what belongs to the change if nothing is staged yet. Never
git add -A over unrelated edits without saying so.
- Commit on a branch, not on
main. If git branch --show-current reports the default branch, say so and ask first.
- Do not push unless asked.
