WHEN TO USE IT
When you want commit messages that describe why, in a consistent format, without writing them by hand.
Formats change. If a field stops working, check it against Anthropic's documentation.
disable-model-invocation keeps Claude from committing on its own initiative; allowed-tools pre-approves only the git commands it needs, for this turn only.
---
name: commit-message
description: Write a Conventional Commits message for the staged changes and commit them.
disable-model-invocation: true
allowed-tools: Bash(git diff *) Bash(git log *) Bash(git commit *)
argument-hint: [optional note about intent]
---
Write a commit message for the staged changes and commit them.
1. Run `git diff --staged`. If nothing is staged, stop and say so —
do not stage files yourself.
2. Run `git log --oneline -10` and match the repository's existing style.
3. Write the message:
- Subject: `type(scope): summary` — feat, fix, docs, refactor, test,
chore, perf. Imperative mood, under 72 characters, no full stop.
- Body: why the change was made and anything a reviewer must know.
Wrap at 72. Skip the body for a trivial change.
- Footer: `BREAKING CHANGE: ...` when a public API changed.
4. Commit with that message.
Extra context from the user, if any: $ARGUMENTS
The folder name becomes the command. Claude Code watches the skills folders, so a new skill is usually available without a restart.
# this project — commit it to share with the team
mkdir -p .claude/skills/commit-message
mv SKILL.md .claude/skills/commit-message/
# or: for you, in every project
mkdir -p ~/.claude/skills/commit-message
mv SKILL.md ~/.claude/skills/commit-message/
# then, inside Claude Code:
# /commit-message fixes the login timeout
MORE SKILLS
The authority
Anthropic's documentation for Skills
This template is a starting point. Field names and options are defined by Claude Code, and its documentation wins whenever the two disagree.
https://code.claude.com/docs/en/skills