Commit Message Writer
Turns a staged git diff into a clean Conventional Commits message — correct type, tight summary, and a body that explains why, not what.
What this skill does
Key features
- Reads the staged diff before writing anything — never guesses
- Enforces Conventional Commits (type(scope): summary, ≤72 chars)
- Writes a body explaining the reason for the change, wrapped at 72 cols
- Refuses to invent changes that aren't in the diff
Use cases
- Consistent commit history across a team
- Automating commit messages in an agent-driven workflow
- Teaching juniors what a good commit looks like
SKILL.md
The skill definition — its metadata and the exact instructions an agent follows. Copy it into a SKILL.md file in your agent's skills folder.
| name | commit-message |
|---|---|
| description | Write a Conventional Commits message from the staged git diff. |
| allowed-tools | Bash(git diff:*), Bash(git status:*), Read |
| scope | single commit |
Musts
- Run
git diff --stagedand read the actual changes before writing anything. - Use Conventional Commits format:
type(scope): summary. - Keep the summary line in the imperative mood and ≤72 characters.
- The body (if any) explains why the change was made, not a restatement of the diff. Wrap at 72 columns.
- Never describe changes that are not present in the staged diff.
Guidelines
- Prefer these types:
feat,fix,docs,refactor,test,chore,perf. - Omit the scope if it isn’t obvious; don’t invent one.
- Reference an issue in the body (
Refs #123) only if the user provides it.
Example
Input (staged diff): a new rate-limiter added to the login route.
feat(auth): rate-limit login attempts
Brute-force attempts were unbounded. Adds a 5-attempts-per-minute
limiter per IP on the login route to slow credential stuffing.FAQ
Does it commit automatically?
No. It only reads the diff and produces the message text; you review and commit. Keep a human in the loop for anything that writes history.
What if the diff is huge?
It summarises the dominant change and notes secondary ones. For very large diffs, consider splitting into focused commits first — the skill will suggest this.
Before running any skill, read its instructions and the tools it's allowed to use, and test it on a safe target first. See LLM security best practices.