| name | generate-conventional-commit-messages |
| allowed-tools | Bash(git diff *) Bash(git log *) Bash(git status *) Bash(printf * pbcopy) |
| description | Generates commit messages in Conventional Commits format based on staged changes (git diff --staged). Use this skill whenever the user asks to generate a commit message, create a commit, write a git commit, or format a commit. Also trigger when the user says things like "create a commit message", "what should my commit message be?", "help me commit this", or mentions "conventional commits". Even if the user just says "commit" without additional context, consider using this skill to produce a well-formed message.
|
Generate a commit message in conventional commits format based on staged changes (git diff --staged).
Show the commit message only — never perform git operations like git commit.
Keep in mind that the commit message will appear in release notes, so it should be clear and concise.
Pre-check
Before inspecting staged changes, always run git log --oneline -5 first. The user may have already committed (e.g., via pre-commit hooks or manually). If the latest commit already covers the current work, generate a message for git diff --staged only if there are additional staged changes.
Type Selection
Choose the type based on what was changed and why. Decide by the
class of artifact and whether shipped-program runtime behavior changed —
never by how much a user could be inconvenienced.
-
First, identify the nature of the change:
- Documentation only →
docs
- Build/CI configuration →
ci or build
- Code style/formatting →
style
- Tests only →
test
- Chores (deps, cleanup) →
chore
- Code restructuring without behavior change →
refactor
Stop-gate: if the diff touches ONLY non-code artifacts (docs, build/CI
config, tooling scripts, comments, metadata, reference strings like URLs or
repo names), the type is settled here — do NOT proceed to step 2. A change
to such artifacts is never feat/fix even if it is "wrong/broken" or would
inconvenience a user, because the program's runtime behavior does not change.
For a mixed non-code diff (e.g. docs + tooling + comments) use chore.
-
For changes to shipped-program runtime behavior, ask: "Did this
functionality exist before?"
- No, this is genuinely new →
feat
- Yes, but it was wrong/broken/non-compliant →
fix
Common mistakes to avoid:
- BREAKING CHANGE does not imply
feat — a spec-compliance fix can be fix!
- Large code changes do not imply
feat — size is irrelevant
- API signature changes do not imply
feat — if correcting a mistake, use fix
- User-facing inconvenience does not imply
fix — a stale install URL in the
README or a broken link in a comment is docs/chore; fix requires the
program's own behavior to have been wrong
Line Length
- Title: Keep concise — no strict character limit, but shorter is better
- Body: Wrap at 72 characters per line for readability in
git log
Atomic Commits
Split staged changes into separate commits by logical unit. Each commit
should be independently reviewable and contain one cohesive change.
When the diff contains multiple logical changes, suggest multiple commit
messages with explicit git add instructions for selective staging.
Exclusions
Do NOT include:
- Phase/step numbers (e.g., "Phase 1", "Step 2")
- Plan or task references (e.g., "As part of...", "Following the plan...")
- Internal implementation context
Before outputting, verify the message contains none of the above.
Clipboard
After generating the commit message(s), copy to the clipboard using pbcopy.
When copying to the clipboard, do NOT insert a blank line between the title and body. The title and body should be separated by a single newline only (e.g., printf 'title\nbody' | pbcopy).
When there are multiple commits, run a separate printf ... | pbcopy for each commit message. Do NOT combine multiple messages into a single pbcopy call — the user will commit one at a time and needs the clipboard to contain only the current message.
The user-facing output should retain blank lines between title and body for readability.
